From: "Mike Stump" <mikestump@xxxxxxxxxxx>
Sent: Friday, August 01, 2014 11:24 PM
On Aug 1, 2014, at 12:01 PM, Jakub Narębski <jnareb@xxxxxxxxx> wrote:
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.
So, as a dumb user that just wants it to work, I am unsympathetic to
the `but software is hard’ excuse. I am aware that some bugs are
harder to fix than others. svn took a long time to fix this bug, but
they did. I can wait, the only question is, will it be a week, a
month, a year, or a decade.
When merging Git uses only what is being merged and its common
ancestor (3-point merge). It is simple, and simple works!!!
I gave a solution for git using branches and it works just fine. It
retains the simple 3-point merge as well.
At the moment there is no formal way for Git to record within the commit
metadata the inclusion of the cherry-picked diff (the 'merge' of the
fix).
Thinking out of the box, the issue is that the commit parents list does
not have a formal mechanism to allow the recording that the 'merged'
change was the patch change from a specific commit fom somewhere else
(which may be missing from the local repo).
Perhaps it needs a style of merging-rebase where a second (last) parent
is added but it isn't the straight <sha1>, but says 'patch-<sha1>', such
that readers with the capability could check if that <sha1> history is
present locally, and if so if it's correct, so that you can now 'track'
your fixes between releases, and (hopefully) older Gits don't barf on
that extra 'fake' parent. Somehow I suspect that older Git's would
barf.. (not enough time to create and test such a fake commit)
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.
Im the solution that I sketched in my previous email, that information
is then exposed so that the right merge happens.
The rebase command handles
I can’t use rebase as it is unfriendly to coworkers.
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?
No, not yet. I’m not as interested in using it, as I would like git
itself to just work.
--
Philip
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html