← Back to team overview

dhis2-devs-core team mailing list archive

Re: backporting in github

 

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

Follow ups

References