Re: [PATCH] Enable tree (directory) history display

[Luben Tuikov <ltuikov@yahoo.com>]

--- Linus Torvalds <torvalds@osdl.org> 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