Re: how to keeping track of cherry-pick?

[Michael J Gruber <git@drmicha.warpmail.net>]

Knut Olav Bøhmer venit, vidit, dixit 21.01.2009 09:44:
> Junio C Hamano wrote:
>> Knut Olav Bøhmer <knut-olav.bohmer@telenor.com> writes:
>>
>>> svnmerge.py can give us a list of revisions available for merging. The
>>> result is similar to "git log --chery-pick master..dev" The difference
>>> is that svnmerge.py operates on revision-numbers, and --chery-pick looks
>>> at the diffs. The result of that is that when we get a conflict when a
>>> patch is cherry-picked, it will still show up as "available" when I run
>>> "git log --cherry-pick master..dev"
>> I think you are looking at it a wrong way.
>>
>> Because subversion (at least the older one) does not keep track of merges,
>> you had to track cherry-picks.  But cherry-pick is not how you usually do
>> things in git.  You keep many topic branches with different doneness, and
>> you merge well-cooked ones to the more stable integration branch while
>> leaving others still cooking.  So what you want to know is not cherry-pick
>> status, but merge status.
> 
> 
> I was afraid I would get this answer. I know that you change your
> workflow when you migrate to git, but I was looking for a way to resolve
> the situation we are in, due to our old vcs.

In the transition phase, while you still have to work off your
un-gittish svn feature branches, you can mimick svnmerge.py's blocking
at least somewhat: If you merge that branch (or a commit on that branch,
i.e. that branch up to that commit) using "git merge -s ours" then git
records a merge but does not change your base branch. This effectively
blocks all commits up that one from being merged in subsequent merges:
They're recorded as merged, but they are not "applied".

The disadvantage is that you have to go through your svn feature branch
sequentially, merge what you want to keep, merge -s ours what you want
to block. You can't easily "unblock" later because that would mean
reverting a merge.

For sure, the better option is to rip your svn feature branch apart into
git feature branches as Junio suggests, maybe using one of the patch
queue like "extensions" to git.

Michael