dhis2-devs-core team mailing list archive

[Morten Olav Hansen <morten@xxxxxxxxx>]

Yeah, probably a better way... work in your own fork, then when you are
ready to merge.. git latest updates.. merge it locally in the fork, and
then you can join the `trunk` with a single message.. but the git tree will
still reveal all details, which is good I guess :)

-- 
Morten Olav Hansen
Senior Engineer, DHIS 2
University of Oslo
http://www.dhis2.org

On Fri, Jun 3, 2016 at 8:11 PM, Lars Helge Øverland <lars@xxxxxxxxx> wrote:

> A third way I guess is to use your own dev branch, and then merge stuff
> into master through pull requests in larger chunks.
>
> This could be healthy since we could avoid some of the "Minor" commits
> (yours truly is the biggest offender here).
>
> Like discussed this changes our workflow so good to think through.
>
> On Fri, Jun 3, 2016 at 8:40 AM, Morten Olav Hansen <morten@xxxxxxxxx>
> wrote:
>
>> Actually, my biggest complain with moving over.. is related to github,
>> unless you are using some kind of hook.. I don't see any option for getting
>> full diff in every email (like we do in launchpad), of course.. you can
>> just click the link to get it.. but I feel this is a + on the launchpad/bzr
>> side..
>>
>> --
>> Morten Olav Hansen
>> Senior Engineer, DHIS 2
>> University of Oslo
>> http://www.dhis2.org
>>
>> On Fri, Jun 3, 2016 at 7:39 PM, Morten Olav Hansen <morten@xxxxxxxxx>
>> wrote:
>>
>>> Yeah, I think we all should stay away from rebase ;) it's a very
>>> powerful tool.. but it's easy to wrec havoc.. I think as a minimum, before
>>> we start using GIT for DHIS 2.. there should exist a `tips and tricks` or
>>> `git for bzr users` markdown document for us on github.. explaining how to
>>> mimic bzr workflow in GIT..
>>>
>>> bzr also have some kind of rebase... but it's never really been working
>>> ;) (of course it doesn't help that everyone on the bzr team was fired of
>>> moved around a couple of years ago)
>>>
>>> --
>>> Morten Olav Hansen
>>> Senior Engineer, DHIS 2
>>> University of Oslo
>>> http://www.dhis2.org
>>>
>>> On Fri, Jun 3, 2016 at 7:33 PM, Nicolay Ramm <nicolay@xxxxxxxxx> wrote:
>>>
>>>> There are two ways you can avoid this:
>>>>
>>>> The simplest is to emulate the bazaar workflow: Always do a pull before
>>>> you commit, and then immediately push. As long as nobody else has pushed
>>>> any new commits between your pull->push, you will end up with a linear
>>>> commit log. If there are conflicts you may also have to stash your changes
>>>> before a pull will go through, and then manually resolve the conflicts
>>>> afterwards.
>>>>
>>>> The other way is to use git rebase instead of git pull. This is a
>>>> potentially dangerous operation because it rewrites historical commits,
>>>> which can screw up other people's repos. Therefore you have to make sure
>>>> that you haven't pushed your local commits before you rebase.
>>>>
>>>> Here's a good guide:
>>>> https://www.atlassian.com/git/tutorials/merging-vs-rebasing
>>>>
>>>> The easiest option is just to live with the merge commits though ;)
>>>>
>>>>
>>>>
>>>> Nicolay Ramm
>>>> Front end developer, DHIS 2
>>>> University of Oslo
>>>> https://www.dhis2.org
>>>>
>>>> On Fri, Jun 3, 2016 at 2:16 PM, Morten Olav Hansen <morten@xxxxxxxxx>
>>>> wrote:
>>>>
>>>>> Speaking as a GIT novice here.. if we end up switching to git for DHIS
>>>>> 2, do we still need all these merge commits? whenever I use some time on
>>>>> docs... I always end up being outdated.. so I commit locally, and then have
>>>>> to git pull.. merge inn local + updates.. then commit.. which is OK i
>>>>> guess, but it's a very different approach from bzr..
>>>>>
>>>>> --
>>>>> Morten Olav Hansen
>>>>> Senior Engineer, DHIS 2
>>>>> University of Oslo
>>>>> http://www.dhis2.org
>>>>>
>>>>> On Sun, May 22, 2016 at 8:14 PM, Lars Helge Øverland <lars@xxxxxxxxx>
>>>>> wrote:
>>>>>
>>>>>> Okay great.
>>>>>>
>>>>>> Assuming that the 2.23 branch is already existing.. Wouldn't you use *git
>>>>>> checkout* here?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, May 22, 2016 at 2:46 PM, Mark Polak <mark@xxxxxxxxx> wrote:
>>>>>>
>>>>>>> I do something similar, but generally for the docs repo where there
>>>>>>> are no local dependencies. There isn't really a reason to keep the repo in
>>>>>>> a separate map..
>>>>>>>
>>>>>>> if you do a git pull it should update all your local branches in the
>>>>>>> same folder to do the cherry pick the only thing you'd really have to do is
>>>>>>>
>>>>>>> git branch 2.23
>>>>>>> git cherry-pick  <hash>
>>>>>>> git push (or git push origin 2.23)
>>>>>>> git branch master
>>>>>>>
>>>>>>>
>>>>>>> On Sun, May 22, 2016 at 1:42 PM, Jim Grace <jim@xxxxxxxxx> wrote:
>>>>>>>
>>>>>>>> Sounds good to me, unless someone knows a better way.
>>>>>>>>
>>>>>>>> On Sun, May 22, 2016 at 6:40 AM, Lars Helge Øverland <
>>>>>>>> lars@xxxxxxxxx> wrote:
>>>>>>>>
>>>>>>>>> Hi devs,
>>>>>>>>>
>>>>>>>>> as we use GitHub increasingly more we should find a standard way
>>>>>>>>> of "back-porting" commits to release branches, similar to how we do it on
>>>>>>>>> Launchpad.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This is the procedure I use. This example uses the dhis2-docs
>>>>>>>>> repo. First clone the actual branch to avoid having to checkout/switch
>>>>>>>>> between branch and master all the time.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    - git clone -b 2.23 git@xxxxxxxxxx:dhis2/dhis2-docs.git
>>>>>>>>>    dhis2-docs-23
>>>>>>>>>
>>>>>>>>>    - cd dhis2-docs-23
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Then use *cherry-pick* to apply a commit from master to the
>>>>>>>>> branch and push to branch.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>    - git cherry-pick 3a6e47ea7a054f95967b3d0a0671fc649b7878c0
>>>>>>>>>
>>>>>>>>>    - git push origin 2.23
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I know there are multiple ways to do this. Let me know if this
>>>>>>>>> sounds okay or if there are better ways.
>>>>>>>>>
>>>>>>>>> Lars
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Lars Helge Øverland
>>>>>>>>> Lead developer, DHIS 2
>>>>>>>>> University of Oslo
>>>>>>>>> Skype: larshelgeoverland
>>>>>>>>> lars@xxxxxxxxx
>>>>>>>>> http://www.dhis2.org <https://www.dhis2.org/>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Mailing list: https://launchpad.net/~dhis2-devs-core
>>>>>>>>> Post to     : dhis2-devs-core@xxxxxxxxxxxxxxxxxxx
>>>>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs-core
>>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Jim Grace
>>>>>>>> Core developer, DHIS 2
>>>>>>>> HISP US Inc.
>>>>>>>> http://www.dhis2.org <https://www.dhis2.org/>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Mailing list: https://launchpad.net/~dhis2-devs-core
>>>>>>>> Post to     : dhis2-devs-core@xxxxxxxxxxxxxxxxxxx
>>>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs-core
>>>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>>
>>>>>>>
>>>>>>> Mark Polak
>>>>>>> Software developer, DHIS 2
>>>>>>> University of Oslo
>>>>>>> http://www.dhis2.org <https://www.dhis2.org/>
>>>>>>> mark@xxxxxxxxx
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Lars Helge Øverland
>>>>>> Lead developer, DHIS 2
>>>>>> University of Oslo
>>>>>> Skype: larshelgeoverland
>>>>>> lars@xxxxxxxxx
>>>>>> http://www.dhis2.org <https://www.dhis2.org/>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Mailing list: https://launchpad.net/~dhis2-devs-core
>>>>>> Post to     : dhis2-devs-core@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs-core
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Mailing list: https://launchpad.net/~dhis2-devs-core
>>>>> Post to     : dhis2-devs-core@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~dhis2-devs-core
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>
>>
>
>
> --
> Lars Helge Øverland
> Lead developer, DHIS 2
> University of Oslo
> Skype: larshelgeoverland
> lars@xxxxxxxxx
> http://www.dhis2.org <https://www.dhis2.org/>
>
>