Fwd: cherry picking and merge
- From
Jakub Narębski <jnareb@gmail.com>
- Date
- Aug 1, 2014, 19:01 UTC
- Message-ID
- <CANQwDwdKbmqLSLGsiyHTfGNZGfbeNZM3TN6Zk0G5G-8twRc_JQ@mail.gmail.com>
- In-Reply-To
- <CANQwDwc4YPdK+a0Oc-jWPTRyM5GiP-CMuRY1inxJY41GwUGBvQ@mail.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