Re: Following renames

(Note that I do *not* want to raise the explicit vs. implicit rename tracking argument, in case anyone would misunderstood. I've accepted implicit rename tracking as a fact of Git life for now. I just want to make use of it now. ;-)

Dear diary, on Sun, Mar 26, 2006 at 04:49:48AM CEST, I got a letter where Junio C Hamano <junkio@cox.net> said that...

Well, noone argues that rename tracking cures all the woes of hackerkind and anything more precise than that is useless. I'm rather saying that rename tracking indeed _is_ a special case of something more general and truly very interesting, but a special case so frequent that it's worth doing even if we can't do the general case yet. Or at least people *think* it's very frequent and it gives them the warm fuzzy feeling knowing that the tool can handle it (at least somehow) - and the warm fuzzy feeling is important, especially if you're trusting your sources to the tool.

So, obviously, you'll find plenty of counter-examples where rename detection won't help. I don't argue that. I merely say that there will still be enough cases where following renames will help to warrant doing it.

Now, Git history has enough examples of where rename following would be useful. When I'm digging into the history, I'm hitting the big tools rename barrier all the time, and just yesterday when wondering about jdl's <snap> removal from git.txt I've hit 2cf565c53 - coming along any file to that commit should make me follow Documentation/core-git.txt out of the commit (well, that's rather copy than rename detection).

A wild pickaxe - when the string disappears from file X, scan all the changes in the commit and start following files where it reappears. This should help, right?

But when you want to implement this, you hit the exact same problems as when you try to follow renames, only a different part of diffcore detects it. So, what I'm trying to solve is actually not just following renames but a more general problem.

If in doubt (and the user does not use pickaxe to clarify it), you can just follow both. The user will get some extra stuff (or maybe even not if he wants to know about pieces from both), but we are at least trying to be useful and DTRT instead of doing nothing in case we would by any chance not do the very best.

A frequent (and wanted) special case.

Sure, pickaxe is cool, but as I said above, if you try to teach _it_ following around files, you'll hit the exact same problems as me. We're just trying to build something using lego blocks with different stuff inside but otherwise actually looking pretty much the same.

The thing with pickaxe is that frequently it would be simply more laborous to dig for and construct the proper pickaxe string than just firing up cg-log -s filename with greedy renames following and quickly scanning through the results.