Re: Multi-branch committing in git, revisited - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Multi-branch committing in git, revisited
Date
Msg-id AANLkTimpwV4G+8Vfhocsc=+f7W_js8Sz2f=W6fmLUFyL@mail.gmail.com
Whole thread Raw
In response to Re: Multi-branch committing in git, revisited  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Multi-branch committing in git, revisited  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Wed, Sep 22, 2010 at 05:47, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bruce Momjian <bruce@momjian.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
themall automatically) 
* Have a working repo, where I do my changes. Each branch gets a checkout when necessary here, and this is where I
applyit. 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
gitcommit -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...

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


pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Configuring synchronous replication
Next
From: Dave Page
Date:
Subject: Re: Configuring synchronous replication