Fwd: cherry picking and merge

["Jakub Narębski" <jnareb@gmail.com>]

[sorry for duplicate sent as private mail; I forgot to turn off HTML
when sending to the git mailing list]

On Fri, Aug 1, 2014 at 7:48 PM, Mike Stump <mikestump@comcast.net> wrote:
[...]
>
> I was curious if svn handles this better the same or worse, and it did it just fine.  I know that a while ago, svn could not handle this, it would do what git does currently.  Apparently they figured out it was a bug and fixed it.  Have you guys figured out it is a bug yet?  The first step in solving a problem, is admitting you have a problem.


It can work in Subversion because Subversion stores information about
what was merged in (and this includes cherry-picks, or whatever it is
named in svn) in svn:mergeinfo property. Git does not track what was
merged in, instead it represent the history as the graph of revisions,
and tracks merges (by storing that it came from two or more commits)
and not merged-in information.

When merging Git uses only what is being merged and its common
ancestor (3-point merge). It is simple, and simple works!!!
Unfortunately, it does not see cherry-picked commits - it is invisible
to merge as being on the chain from one of merged commits to the
common ancestor.

The rebase command handles cherry-picked commits by detecting that the
change was already applied. I think that git-imerge does the same (but
I have not used it myself).

Have you tried git-imerge?

-- 
Jakub Narębski



-- 
Jakub Narebski