Re: Multi-branch committing in git, revisited

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Magnus Hagander <magnus(at)hagander(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:47:26
Message-ID: 4C99ECCE.7060609@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2010-09-22 11:48:39 Re: Multi-branch committing in git, revisited
Previous Message Magnus Hagander 2010-09-22 11:45:03 Re: snapshot generation broken