Re: Multi-branch committing in git, revisited
От | Andrew Dunstan |
---|---|
Тема | Re: Multi-branch committing in git, revisited |
Дата | |
Msg-id | 4C99ECCE.7060609@dunslane.net обсуждение исходный текст |
Ответ на | Re: Multi-branch committing in git, revisited (Magnus Hagander <magnus@hagander.net>) |
Ответы |
Re: Multi-branch committing in git, revisited
|
Список | pgsql-hackers |
On 09/22/2010 07:07 AM, Magnus Hagander wrote: > 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 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
В списке pgsql-hackers по дате отправления: