Re: Git log follow question

On Fri, 14 May 2010, Jeff King wrote:

I'm pretty sure I mentioned about this exact issue when I posted the original follow patches, and it basically boils down to: "--follow" is a total hack, and does _not_ use the regular commit filtering function, and as a result, fancy things like "--parent" don't really work well with it.

IOW, I'm not at all certain that it is fixable. "--follow_ is a very fundamentally non-gitty thing to do, and really is a complete hack. It's a fairly _small_ hack - if you didn't know better and looked at the source code, you might think that it fits very naturally into git. But no.

Now, it's possible that we could hack up --parent to work with --follow too, but quite frankly, I don't know how. Because the --follow hack really basically boils down to:

 - do _not_ prune commits at all (this the the thing that normally 
   simplifies the parenthood and removes uninteresting commits)

 - for the whole list of normal commits in "git log", do the patch 
   generation with a magic special hack that looks for renames.

 - if it was a rename, change the path that we magically track, so that 
   next commit that we look at, we'll follow the new (older) path.

 - if the patch is empty, we force-hide the commit (internally, this is 
   the "rev->always_show_header = 0;" thing)

and the key here is that we do all the magic at the _end_ of the queue, long after we've done the pruning of commits that normally does the parenthood renaming.

If we want --follow and --parent to work together, you'd need to move the special rename hack to be in the early phases. I'm sure it's possible. It might even be reasonably simple. But it's very fundamentally not what we do now.

And no, I'm unlikely to look at it. Sorry. I have used --follow occasionally, but it's a hack to see "ok, there it got renamed". It would be nice if "gitk --follow <pathname>" worked properly, but it's just not something I care very much about.

			Linus