--- Linus Torvalds <torvalds@xxxxxxxx> wrote:
> That count of 145 is the number of commits that actually _change_ Makefile
> some way - and some of them really are merges, because they have a content
> merge, and the merge result is thus different from any of the children. So
> that's a real number. So is 136, in some sense - it just says that we
> don't care about commits, even if those commits _do_ end up changing the
> file.
Indeed, I got the same conclusion using different branches.
(Sorry, I thought your email was from Junio in my last email, it was
your analysis after all.)
> But the important part to realize is that the "971" number is always
> wrong. It's never a really valid number. It contains a lot of extra
> merges, but it does _not_ contain enough of them to connect all the dots,
> and it's thus never correct. Either you should drop merges that don't
> change things (in which case you cannot have full connectivity, and
> "--parents" doesn't make sense), or you should keep them all (or at least
> enough to get full connectivity).
Yes, that makes sense.
Ok, I get similar numbers as you do. After the patch, compared to
the simple case of git-rev-list HEAD -- <path spec>, --parents gives
me only one more commit which is the very first hand made kernel
commit ;-) ; --parents --full-history gives me way too many unrelated
commits about 10x as many; --full-history gives me a _complete_ list.
The simple case fails to report a few commits which are
due to merges, which do indeed change files in the path spec.
(--full-history successfully reported those though).
So your patch plus "--full-history" is what I think we want.
Luben
-
: 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