Re: Git log follow question

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: May 25, 2010, 18:49 UTC
Message-ID: <alpine.LFD.2.00.1005251141580.3689@i5.linux-foundation.org>
In-Reply-To: <20100525093140.GA32460@coredump.intra.peff.net>

On Tue, 25 May 2010, Jeff King wrote:

Show 6 quoted lines

> 
> Thanks for the input. I took a look at it myself and it is a bit more
> complex than just turning on pruning. I have a prototype --follow that
> handles arbitrary pathspecs instead of single files; instead of
> replacing the single-file pathspec, it just widens the pathspec as it
> traverses history.

Doing it "right" is actually a _lot_ more complex than that.

Think especially about the case of the file having been renamed in one branch, and in another branch it was created from scratch, and then a merge that sorts it all out (think two people aiming for the same thing, just doing it differently - but with similar approaches).

Now, imagine reaching the common commit by walking _one_ of the chains before having walked the other one fully. So now you're looking at a commit using one set of pathnames, and then later on you'll hit the _same_ commit (through the other branch), but with another set of pathnames. But by then you've already handled that commit.

The above isn't an issue with the regular pathname pruning, because the pruning rules never change - so the order of handling commits never matter, and you can do the pruning before/independently of having done any history following.

And it's not an issue with the current total hack, because the current total hack doesn't even _try_ to handle it, and doesn't even really try to do anything proper. The current hack is very much by design was a "hey, this is about as good as CVS/SVN could ever do", rather than anything that has any good design.

		Linus