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

From: Luben Tuikov <ltuikov@yahoo.com>
Date: Jul 1, 2006, 22:45 UTC
Message-ID: <20060701224510.38530.qmail@web31806.mail.mud.yahoo.com>
In-Reply-To: <Pine.LNX.4.64.0606302029310.12404@g5.osdl.org>

--- Linus Torvalds <torvalds@osdl.org> wrote:

Show 6 quoted lines

> 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.)

Show 7 quoted lines

> 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