dhis2-devs-core team mailing list archive

[Morten Olav Hansen <morten@xxxxxxxxx>]

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
>>
>>
>