Philip Oakley wrote:
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.
Here Git and Subversion went in different directions, and use
different mechanisms (merge tracking vs merged-on tracking).
Both have their advantages and disadvantages.
git-merge (in the most usual case) depends only on three revisions:
the revision you merge into (current branch, ours), the revision
you are merging (merged branch, theirs), and merge base (common
ancestor). We could have another merge strategy that examines
contents of revisions to handle cherry-picks and reverts... but
it would be more complicated, and much slower.
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.
It works for this simple case, but I think it has unfortunate potential
to go silently wrong.
Also, it prevents fully removing (commits, not only refs) the branch
you cherry-picked from. The commit you cherry picked may no longer
be (or may no longer should be) in the repository.
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).
Sometime ago there was long discussion about adding 'weak' references
to commit object header.
Beside the problem of backward compatibility, there was also the problem
of semantics of said reference - what does it mean? It should work as
well for cherry-picks, for interactive rebase (maybe?), and for reverts
(which are also a problem).
Also, this could be avoided by using feature branches and merging
instead of committing to one branch and cherry-picking to other
branches. Also, git-rerere is your friend... sometimes.
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.
Maybe this command would make it into git proper, though probably
not written in Python (there was once merge strategy written in Python,
but currently git does not depend on Python).
--
Jakub Narębski
--
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