Re: Following renames

On Sun, 26 Mar 2006, Jakub Narebski wrote:

BK had this "renametool" which got started automatically when you applied a patch that removed one or more files and added one or more files, so that you could then pair up the files manually.

It left the rename pairing 100% to the user, but it helped a bit by guessing what the pairing might be, and yes, it used the basenames to set up that initial guess.

It worked in many cases, but it also failed in many cases. I do think it was a useful heuristic within the BK model (since the _real_ choice was left to the user), but I don't think it's very useful for git.

The thing is, the fast rename detection that is in the "next" branch really does a lot better, and it's fast enough.

(If you wanted to make it even faster, but less precise, you could limit it to the first few kilobytes of file contents - still a _lot_ better heuristic than the actual filename, and it would make the worst-case behaviour much better).

I don't have any numbers, but from usign renametool for a few years, my gut feel/recollection is that about half of renames in the kernel were moving to a new directory, and about half changed names (often in _addition_ to moving). But I didn't much think about it, so that's just a very rough guess based on using a tool that helped you do these things manually.

For example, one common case was a directory structure like

	..
	type-file1.c
	type-file2.c
	otherfiles.c
	yet-more.c
	..

being split up into a subdirectory

	..
	type/file1.c
	type/file2.c
	otherfiles.c
	yet-more.c
	..

(eg drivers/scsi/aic7xx-* being given a subdirectory of it's own, as drivers/scsi/aic7xx/*). So the basename wouldn't stay the same, because it contained some piece of data that became redundant with the move.

Yes. I don't think we necessarily want to merge automatically across things like that, even if it sounds like something you'd want in a perfect world. Stupid and obvious (and fails) is often better than smart and complex (and succeeds), because at least you _understand_ what happens.

But _following_ a particular change back is important, and should be both efficient and simple to do. Ie the example tool I talked about in

        http://article.gmane.org/gmane.comp.version-control.git/217

is still relevant and important, I think.

I literally think that people wouldn't even _want_ a "git annotate", if they instead had more of a visual tool that showed the current state of the file, and you could click on a line/set of lines to follow it back to the previous change to that area. I'd argue that almost always when you want "annotate", you already have the particular place that you want to look at in mind (you're really not interested in the whole file).

So wouldn't it be _much_ nicer to have a "graphical git-whatchanged", where you just delve deeper (and you don't even look at the whole file like git-whatchanged does, but you ask for a very particular region).

Ie, what I imagine would be something gitk/qgit like, where you see the file content, select a line or two (or a whole function), and it goes back in history and shows you the last diff that changed that line/two/function. We can do that EFFICIENTLY. Much more efficiently than git-annotate, in fact. And then when you see the diff, you might say "I'm not interested in this one, that was just a re-indent" and then continue back.

THAT is the kind of graphical tool I'd want. And dammit, it should even be _easy_. I'm just a total clutz myself when it comes to doing things like QT or nice tcl/tk text-panes, and this really does have to be visual, since the whole point is that "select text" and interactive part.

So if somebody wants to be a hero, and feels comfortable with those kinds of things, this really should be a fairly straightforward thing to do (it would be useful even without rename detection or data movement detection, but it's also something where you really _could_ do efficient data movement detection by just looking at the "whole diff" when something changed in that small area).

		Linus