[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Fixes in Git (first in stable, then merge to master)
From:       Johannes Sixt <j.sixt () viscovery ! net>
Date:       2011-07-22 6:37:23
Message-ID: 4E291AA3.3000107 () viscovery ! net
[Download RAW message or body]

Am 7/21/2011 23:22, schrieb Aurélien Gâteau:
> What I have been doing recently to avoid cherry-picking is to create my
> fixes in a separate work branch, then merge the branch in both 4.7 and
> master branches. This way the commits do not have different commit ids.

But this works only if you fork off your topic from a commit that is in
both 4.7 and master, i.e., before 4.7 and master forked. Do you do that?

This is a very reasonable (and git-ish) way to avoid cherry-picks and
still avoid merging 4.7 into master. (But the latter, avoiding to merge
4.7 into master, is very un-git-ish.)

-- Hannes

[prev in list] [next in list] [prev in thread] [next in thread]