Re: Multi-branch committing in git, revisited

Поиск
Список
Период
Сортировка
От Magnus Hagander
Тема Re: Multi-branch committing in git, revisited
Дата
Msg-id AANLkTi==iKUY0Ua8DdfjMNRGZrEyt4W9iHqhZO23KicN@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Multi-branch committing in git, revisited  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
On Wed, Sep 22, 2010 at 13:47, Andrew Dunstan <andrew@dunslane.net> wrote:
>
>
> 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.

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/


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Multi-branch committing in git, revisited
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Configuring synchronous replication