On Sat, 02 Jul 2016 13:52:05 +0000, Stefan Sperling wrote:
...
> And I agree that this argument is missing the point. It claims that because
> a merge may select just a subset of changes committed in a particular revision,
> drawing a "line" to indicate a merge commit would be misleading since not
> all changes from the revision were merged.
> But that is the case for every version control system since merge commits
> are never a 1:1 mapping of changes, e.g. due to conflict resolution.
I'd still say that these are two different things (not merging the
entire tree but only selected files vs. dropping changes in the
actual merges).
In the first cases there is no mergeinfo for the files that are
not merged, and drawing a global merge arrow is arguably wrong.
But in the other case I do record the merge info even
if I then drop a merged-in change, essentially saying
"yes, I dropped this on purpose, and don't bring it
in again in the next merge". And the recorded mergeinfo
for the entire tree should be displayed as a merge info.
> The misconception seems to be that a conceptual 'merge arrow' implied
> a 1:1 mapping of changes, but it does not.
The fun thing is that a a merge is a symmetric operation with
respect to the contents, so if you don't draw the merge arrow
(second parent in git parlance) on that argument, you shouldn't
draw the straight line from the previous to the merge revision
('first parent') either. (Just as you can drop merged-in changes
in a merge conflict resolution you can as well drop changes
from the straight line.)
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Received on 2016-07-04 08:08:25 CEST