Re: Following renames

From: Timo Hirvonen <tihirvon@gmail.com>
Date: Mar 26, 2006, 16:08 UTC
Message-ID: <20060326190836.dbe95a72.tihirvon@gmail.com>
In-Reply-To: <7virq1sywj.fsf@assigned-by-dhcp.cox.net>

On Sat, 25 Mar 2006 18:49:48 -0800 Junio C Hamano <junkio@cox.net> wrote:

> Looking at the evolution of rev-list.c file itself was a good
> exercise to realize that rename tracking (more specifically,
> having whatchanged to follow renames) is not such a useful
> thing (at least for me).

It would be useful for me. I had all files organized in subdirectories, but then noticed it was not good idea because make does not play nicely with subdirs, so I moved all files to top level directory.

Now

    git-whatchanged -p file.c

stops at the big rename. To continue I have to do

    git-whatchanged -p -- <some-commit> <old-filename>

Show 7 quoted lines

> Another example.  Today's tar-tree updates have one interesting
> function I think should belong to strbuf.c, and before merging
> it to the mainline, I may move that function from tar-tree.c to
> strbuf.c.  After that happens, if I run "whatchanged strbuf.c"
> to see where that function came from, I would want it to notice
> it came from tar-tree.c, although it is not a rename at all.
> Just one function moved from a file to another.

Yes in this case you can do

$ git-whatchanged strbuf.c $ git-whatchanged tar-tree.c

but after rename...

$ git-whatchanged old-file.c fatal: 'old-file.c': No such file or directory

$ touch old-file.c $ git-whatchanged old-file.c

Hah, it worked!

Hmm... this works too without the touch-hack:

$ git-whatchanged file.c old-file.c

I wish I had known this before.

Show 9 quoted lines

> What this suggests is that switching the set of paths to follow
> while traversing ancestry chain needs to depend on which part of
> the original file you are interested in.  Marking "this commit
> renames (or copies) file A to file B" is not that useful -- for
> that matter, detecting at runtime like we currently do is not
> better either.  If a file A and file B were cleaned up and
> merged into a single file C, which is in the tip of the tree,
> which one you would want whatchanged to switch following depends
> on which part of the C you were interested in.

OK, maybe following renames is not such a good idea. But for GUIs (gitk, qgit) following renames or even file merges (select a file to follow by clicking it) would be big plus.

-- 
http://onion.dynserv.net/~timo/