how to keeping track of cherry-pick?

how to keeping track of cherry-pick?

[Knut Olav Bøhmer]

Hi,

We are changing from subversion to git. We used to merge revisions from
development branch to stable with svnmerge.py.

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"

svnmerge.py can also mark revisions as blocked, and will not show up in
the list of available revisions.

How can I keep track of cherry-picked patches, and mark patches as
"blocked", in the same (or similar) way as I did in subversion with
svnmerge.py?

-- 
Knut Olav Bøhmer

Re: how to keeping track of cherry-pick?

[Junio C Hamano]

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.

Because git tracks merges, output from "git log master..$topic" gives all
you need to know about $topic.  The command lists changes that are still
not merged to master on the $topic branch.  If it is empty, $topic is
already merged fully to master.  Otherwise you still have things to
merge.

To get a list of topics that have been merged (or not merged) to a
particular integration branch, you should be able to use "git branch" with
its --merged and --no-merged options.  This does not list what commits
each yet-to-be-merged topics have, though.

Re: how to keeping track of cherry-pick?

[Knut Olav Bøhmer]

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.

-- 
Knut Olav Bøhmer

Re: how to keeping track of cherry-pick?

[Michael J Gruber]

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

Re: how to keeping track of cherry-pick?

[Junio C Hamano]

Knut Olav Bøhmer <knut-olav.bohmer@telenor.com> writes:

> 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.

Maybe I should rephrase the answer, then.

I had an impression that you made it sound as if svnmerge.py is a tool
only meant for a workflow of always cherry-picking, but it actually is
not.  It also enhances your SVN experience by giving something closer to
proper merge tracking.  Even though you only mentioned cherry-picks and
merge blocking, if you like things offered by svnmerge.py other than these
two, you might find that git already has them natively.

When your workflow is based on a single large, unfocused, everything
mixed-in, playpen branch, plus one stable integration branch, you have to
cherry pick to keep the stable integration branch sane, and you need a
good tool to help you keep track of what is cherry picked and what isn't
(yet).  Maybe your SCM has such a tool natively, or maybe it doesn't and
needs a third party tool support (similar to users of older SVN needed to
use svnmerge.py for merge tracking) bolted on.

    ---A1--B1--C1--A2--A3--C2--D1--...  playpen kitchen-sink

    ---o---o---o---A1'--A2'--A3'...     stable integration

The workflow when using git is typically merge based, and git lets you
manage topic branches well and helps you merge easily by keeping track of
merges.

I am reading from http://www.orcaware.com/svn/wiki/Svnmerge.py while I am
typing this, but here is a summary:

 (1) Because merge tracking is built-in to git, you do not need "something
     like svnmerge.py" bolted on.  If you have been using topic branches
     in your established SVN-based workflow, you can keep the same
     workflow and git will do the right thing when you merge your
     branches naturally.

 (2) We didn't have need for "cherry-pick tracking" part of what
     svnmerge.py offers, because we do not do cherry-picks as often.

     You can call this shortcoming if you want, but it should be easy for
     you to contribute a patch to add such a tool if you miss this part of
     svnmerge.py; essentially, you need to keep a database of commit
     object names on the "playpen branch" depicted above, and
     corresponding commit objects cherry-picked from them into the
     integration branch.

 (3) We have "listing changes that are available for merging" natively, as
     I've already explained in the previous message.

 (4) Bidirectional merges, merging from multiple branches, reverting
     merges, and merge commit message generation are all native features
     of "git merge".  If you have git, you already have them.  If you do
     not like the merge result, you can always amend it; commit-free-ness
     is listed as if it is a feature but it does not matter here.

 (5) We do not have "merge blocking".  This falls into the same category
     as (2) above.

Re: how to keeping track of cherry-pick?

[Johannes Schindelin]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2356 bytes --]

Hi,

On Wed, 21 Jan 2009, Knut Olav Bøhmer wrote:

> 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.

You could accomodate your workflow by having the newly introduced commit 
notes provide a mapping of which commits reflect which patch, in a way 
introducing equality classes of patches (thereby having the original SHA-1 
of the commit as kind of a "patch id").

But believe me, you would regret it.

If you are working on different topics, and want to apply only some of 
them, you really want to have different topic branches (it is even 
relatively easy to create them using "git checkout -b <new-topic> 
<miscellaneous-branch> && git rebase -i master" and then deleting the 
commits not referring to a certain subject).

The problem with having a single branch is that patches which are 
independent, can touch the same parts of the code, and are hard to manage 
independently.  If you had them in topic branches, merging them 
individually, you could at least use the rerere mechanism to resolve merge 
conflicts for such overlapping topics.

I speak of experience: my current workflow is exactly what you described, 
and I feel the pain.  That's why I said you would regret it, because I 
sure do.

Ciao,
Dscho