On 09/13/2011 05:25 PM, Vincent van Ravesteijn wrote:
> Op 13-9-2011 23:10, Julien Rioux schreef:
>> How can git help me porting patches to the stable branch?
>>
>> Previously with svn I just had two directories, one pointing to trunk
>> one to branch. I made a patch file from trunk by svn diff -r then
>> applied the patch to branch, manually copying the log message. Does
>> git make it any easier?
>
>
> In svn you can already do it easier with 'svn merge' (IIRC):
>     .\branch-20x> svn merge -c 28393 ..\trunk
>
> In git you can something like this with 'git cherry-pick':
>     on branch-20x do:
>         git cherry-pick <sha1-of-a-commit>
>
You can also, of course, use other ways of referring to a commit. E.g.,
if the commit you want happens to be the last one made in master, then:
    git cherry-pick master
will do the trick. (I have "git config alias.cp cherry-pick" because I
do this so much.) If it's two back, then:
    git cherry-pick master^^
will do it.

> The nicest way though is to make your new feature in a new topic
> branch on the top of branch-20x if it is a candidate to be backported.
> Then, when you're ready and happy with it, you merge this topic branch
> into branch-20x.
>
I do this, too, and name all such branches in the form: fit/####, where
"fit" stands for: fixed in trunk. So, having committed to trunk to fix
bug 8295, I immediately do:
    git co branch # switch to branch
    git svn fetch && git svn rebase # update branch
    git co -b fit/8295 # create branch for this bugfix
    git cherry-pick master # copy over the fix from trunk
Now my fix is in fit/8295.

If there was more than one patch involved, then obviously you copy all
of them over, starting with the oldest. (There is notation for this, but
I can never remember it.) It may make sense to compress them, then, into
one patch, which you can do with:
    git rebase -i
The documentation needed to make that work actually appears in the
editor window you will next see. (Very nice touch.)

If this branch gets old, so that we're worried about conflicts, then we
can update it:
    git co fit/8295
    git rebase branch
If all goes well, good. If not, then fix the conflicts, and proceed
according (again) to the documentation that appears. You can do this
when you merge, too, but I prefer to do it before merging. Easier to
keep things in the topic branch.

As Vincent said, if you want to merge into branch, then you just do:
    git co branch
    git merge fit/8295
or you can use cherry-pick if you prefer. Probably more or less equivalent.

The "fit/####" naming allows me to have this silly little script, named
"git-show-fit":
    for i in $(git branch | grep -P '^\s*fit/' | sed -e 's/\s*fit\///'); do
        firefox http://www.lyx.org/trac/ticket/$i;
    done
and another alias:
    git config alias.show-fit !/home/rgheck/scripts/git-show-fit
so now
    git show-fit
shows me, in Firefox tabs, all the bugs associated with patches I have
waiting for branch.

Richard

Reply via email to