also sprach Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> [2007.10.23.2024 +0200]:
> So it does look at the commits only in the sense that it uses the "shape"
> of the history (which is obviously built up from many individual commits!)
> but it never looks at any individual commit per se.
I don't follow what you mean with "shape". The following is
a history:
o - x - o - o - o - m - o - A* - o - m2 - o - master
\ / /
`o - A - L -' - F - o - o - T' - branch
A is a commit, A* is the commit which reverts (the data change by)
A. L and F are to mark the last and first commits before and after
the first merge m. T is the tip of 'branch'
After merge point m2, the change introduced by A will *not* be in
master. This much makes sense.
What did not make sense is how Git determines to leave it out. But
I think that after drawing the above, it's now clear:
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.
Or as you put it:
> If Foo has had *new* commits in the meantime, those new commits
> will show up, of course, but the old commits have absolutely zero
> effect, because they will be part of the common history.
I think I am (moderately) clear again on the inner working of Git.
Sorry for the confusion.
--
martin | http://madduck.net/ | http://two.sentenc.es/
"the search for the perfect martini is a fraud. the perfect martini
is a belt of gin from the bottle; anything else is the decadent
trappings of civilization."
-- t. k.
spamtraps: madduck.bogus@xxxxxxxxxxx
Attachment:
digital_signature_gpg.asc
Description: Digital signature (see http://martin-krafft.net/gpg/)
