On Tue, 23 Oct 2007, Linus Torvalds wrote:
>
> > by shape you mean the actual graph, and when 'branch' is merged into
> > master at m2, Git goes back in time to conclude that master...L must
> > already be present in master due to the intersection of the two
> > lines at m, and thus finds commit F as the "oldest direct
> > descendant" of m2. L is an older descendant of m2, but it's not
> > direct in the sense that there are multiple paths from m2 to L. Thus
> > Git will only merge F..T at m2.
>
> Exactly.
Side note: strictly speaking, git will not merge "F..T" in the sense that
it never actually even _looks_ at any of the commits in that range per se.
So what it really does is to look at state of the common point ('L') and
then the states of the end-points, and merge things based purely based on
that state, and then join the histories up.
Yes, that *effectively* means merging all the changes from 'F'..'T', but I
want again to point out that the actual changes done by any of the
individual commits in that range are never even looked at. They really are
totally irrelevant on their own.
So if 'F' did a lot of changes and 'T' undid most of them, the merge
algorithm will not ever even *see* those changes. They were irrelevant.
It's not that git sees the changes and then sees that 'T' undid them: git
will literally never actually even look at them in the first place!
That's what I mean by only taking "state" into account. It didn't matter
what any individual commit did. Git won't even have looked at the commit,
other than to find its parent. When git merges, it literally looks at just
the end results, and the last common state(s).
So history matters a great deal to merging, but it only matters in the
global "shape" sense, never in the "per-commit" sense.
Linus
-
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
