On Mon, 13 May 2013 13:29:39 +0000, Les Mikesell wrote:
> ... What does git do if
> you try to double-merge a change?
> Does it know about the previous
> merge by its changeset commit id, look at the contents that are
> already present, or just do it twice?
It doesn't have a notion like "this changeset is merged, that
one isn't, this is again", like in the 3-10,12-14 in the mergeinfo.
Each commit has a parent (or two in the case or a merge commit), and
it just computes the latest common commit and takes that as the
base for a 3-way-merge between the two branches in question.
(Ok, the merge base computation isn't that easy in more complicated
DAGs, but anyway.) If you merge again the end of the source branch
at previous merge time is the new merge base. Merge base computation
is what CVS utterly failed, and SVN for a long time being the better
CVS repeated that.
> I can see why it might be a problem to support concurrent nested
> branch changeset roots but that scenario is problematic any way you
> look at it. Why would it be a problem to support parallel branching
> roots - perhaps with some enforcement on the source/dest top levels
> having some common parent?
I don't think I will understand this paragraph without more
terminology definition or examples.
> > SVN, instead of having branches as a separate concept, also stores whole
> > trees, but instead additionally stores 'this came from there' or 'that
> > was merged here' as a separate concept.
> But does 'that was merged here', really know about the commit
> changeset where the change originated?
Only in the summarily way that it knows when a branch was merged
into another. Everything that is reachable through the commit
parent relation is 'merged in'. You can't selectively
merge specific comments (and record that). You only have
'merge arrows' that tell when everything of a branch was
merged into another, no lists of commits that got merged
(and that make merge algos take forever).
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Received on 2013-05-13 21:13:36 CEST