On Wed, Sep 22, 2010 at 05:47, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Bruce Momjian <br...@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 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...
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
