On Sat, 25 Mar 2006 18:49:48 -0800
Junio C Hamano <junkio@xxxxxxx> 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>
> 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.
> 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/
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html