No, git tracks states and where they came from, not changes per se. That
is, when you look at a commit by David Miller, you're looking at exactly
the file contents that David Miller had when making the commit. Some other
systems linearize history such that what you'd see in Linus's tree is what
David Miller would have had if he'd made his changes to the tree Linus had
before merging David's branch, but that's not the normal thing to do with
git in this case.
Tree E doesn't change versions; it's got the same version as A. But C and
D pick up the version change from B, which means that C and E have
different versions. You could also look at it like this: going back from D
to F changes the version, not because anybody on the lower path changed
it, but because Linus included the version change from his own side when
doing the merge.
2.6.26-rc1 is bad, 2.6.25 is good, vanilla 2.6.25-rc1 is good, but some
modified version of 2.6.25-rc1 was bad. It's like if you take 2.6.25, and
you leave the Makefile the same but change some driver. You can find that
your 2.6.25 is now broken, while the original 2.6.25 is not. What's going
on in this bisect run is that Rene's seeing this same situation, but from
the perspective of looking back from the future and looking at somebody
else's state.
-Daniel
*This .sig left intentionally blank*
--
