Ok, this is interesting.

Try this sequence (which is a good sequence for showign how something like 
"git blame -C" _should_ work, but only ends up showing that it doesn't at 
all, because of some bug ;^):

	#
	# create 'testing' repository
	#
	mkdir testing
	cd testing/
	git init-db

	#
	# copy git.c and sha1_file.c there and commit initial
	# (Just to get _some_ initial state)
	#
	cp ~/git/git.c .
	cp ~/git/sha1_file.c .
	git add git.c sha1_file.c
	git commit -m Initial

	#
	# move the prepend_to_path() function from git.c to
	# sha1_file.c (I did it to just after the
	#	#ifndef O_NOATIME
	# block of preprocessor stuff
	#
	em git.c sha1_file.c
	git commit -a -m Movement
	git log -p

and the result of that "git log -p" should show something like

	commit a583b5aee68b89b7d554b8f900a95057e8ed61d9
	Author: Linus Torvalds <torvalds@woody.osdl.org>
	Date:   Tue Nov 28 20:13:00 2006 -0800
	
	    Movement
	
	diff --git a/git.c b/git.c
	index 357330e..43c01fd 100644
	--- a/git.c
	+++ b/git.c
	@@ -18,28 +18,6 @@
	 const char git_usage_string[] =
	        "git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate] [--bare] [--git-dir=GIT_DIR] [--help] COMMAND [AR
	
	-static void prepend_to_path(const char *dir, int len)
	-{
	-       const char *old_path = getenv("PATH");
	-       char *path;
	-       int path_len = len;
	...
	diff --git a/sha1_file.c b/sha1_file.c
	index 63f416b..20168aa 100644
	--- a/sha1_file.c
	+++ b/sha1_file.c
	@@ -22,6 +22,28 @@
	 #endif
	 #endif
	
	+static void prepend_to_path(const char *dir, int len)
	+{
	+       const char *old_path = getenv("PATH");
	+       char *path;
	+       int path_len = len;
	+
	...

to show how that top commit moved the function. Ok, everything looks fine 
so far.

For the surreal behaviour, now do

	git blame -C sha1_file.c

and watch the result make no sense what-so-ever. It doesn't show the 
movement at all. It shows that everything in that file came from the 
original commit, even though the file obviously did change since.

Which is kind of "true", but it's still _wrong_. Yes, all the data comes 
from the same (initial) commit, but it doesn't come from the same _files_ 
in the same commit, so the fact that we don't see the filenames and 
original lines in those filenames is _broken_. The commit information is 
right, but it's decided not to show all the _other_ information that is 
crucial..

So this shows two problems:

 - the line numbers that "git blame -C" shows are the current line numbers 
   only, not the line numbers it came from in the version it shows. That 
   makes them useless. We _know_ the current linenumbers. What we want to 
   know is what they were in the commit that they came from.

   So right now, the line number information that "git blame -C" shows is 
   just the same thing we could have gotten by doing a "cat -n file".

 - "git blame -C" has apparently decided that it doesn't need to show 
   filenames that things came from, because they all came from the same 
   commit, but that's not a logical thing to compare. "same commit" does 
   not mean "same filename", so not showing the filename makes no sense.

I tried to bisect this a bit, but I don't think pickaxe has ever gotten 
this right, so I couldn't find a place where it was correct to start 
bisecting at ;)

			Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html