Re: Multi-branch committing in git, revisited

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, "David E(dot) Wheeler" <david(at)kineticode(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Multi-branch committing in git, revisited
Date: 2010-09-22 11:48:39
Message-ID: AANLkTi==iKUY0Ua8DdfjMNRGZrEyt4W9iHqhZO23KicN@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Sep 22, 2010 at 13:47, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> On 09/22/2010 07:07 AM, Magnus Hagander wrote:
>>
>> On Wed, Sep 22, 2010 at 05:47, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us>  wrote:
>>>
>>> Bruce Momjian<bruce(at)momjian(dot)us>  writes:
>>>>
>>>> However, keep in mind that creating a branch in every existing backpatch
>>>> branch is going to create even more backpatching monkey-work.
>>>
>>> Monkey-work is scriptable though.  It'll all be worth it if git
>>> cherry-pick is even marginally smarter about back-merging the actual
>>> patches.  In principle it could be less easily confused than plain
>>> old patch, but I was a bit discouraged by the upthread comment that
>>> it's just a shorthand for "git diff | patch" :-(
>>
>> FWIW, here's the workflow I just tried for the gitignore patch (blame
>> me and not the workflow if I broke the patch, btw :P)
>>
>>
>>
>> * Have a master "committers" repo, with all active branches checked out
>>   (and a simple script that updates and can reset them all automatically)
>> * Have a working repo, where I do my changes. Each branch gets a checkout
>>   when necessary here, and this is where I apply it. I've just used
>> inline checkouts,
>>   but I don't see why it shouldn't work with workdirs etc.
>> * In the working repo, apply patch to master branch.
>> * Then use git cherry-pick to get it into the back branches (still in
>> the working repo)
>>   At this point, also do the testing of the backpatch.
>>
>> At this point we have commits with potentially lots of time in between
>> them.
>> So now we squash these onto the committers repository, using a small
>> script that
>> does this:
>>
>>
>> #!/bin/sh
>>
>> set -e
>>
>> CMSG=/tmp/commitmsg.$$
>>
>> editor $CMSG
>>
>> if [ ! -f $CMSG ]; then
>>    echo No commit message, aborting.
>>    exit 0
>> fi
>>
>> export BRANCHES="master REL9_0_STABLE REL8_4_STABLE REL8_3_STABLE
>> REL8_2_STABLE REL8_1_STABLE REL8_0_STABLE REL7_4_STABLE"
>>
>> echo Fetching local changes so they are available to merge
>> git fetch local
>>
>> for B in ${BRANCHES} ; do
>>    echo Switching and merging $B...
>>    git checkout $B
>>    git merge --squash local/$B --no-commit
>>    git commit -F $CMSG
>> done
>>
>> rm -f $CMSG
>>
>>
>>
>> BTW, before pushing, I like to do something like this:
>>
>> git push --dry-run 2>&1 |egrep -v "^To" | awk '{print $1}'|xargs git
>> log --format=fuller
>>
>> just to get a list of exactly what I'm about to push :-) That doesn't
>> mean there won't
>> be mistake, but maybe fewer of them...
>
>
> What a rigmarole! This seems to be getting positively gothic.

FWIW, it's shorter and simpler than what I use for cvs ;) But maybe
that's because I'm being overly careful...

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2010-09-22 11:50:44 Re: Configuring synchronous replication
Previous Message Andrew Dunstan 2010-09-22 11:47:26 Re: Multi-branch committing in git, revisited