Andy Parkins wrote:
quoted text
> It's not really a guess; through the magic of sha-1, and provided you 
> are disciplined enough to commit the rename without any changes to the 
> content you can be sure that the rename is tracked.  The sha-1 /must/ 
> be the same before and after.  For this 100% case, git doesn't even 
> need the "-M", git-blame, git-diff and git-merge will find it anyway.
>   

I said as much in my mail. The problem is that "commit the rename 
without any changes to the content" is synonymous in many cases with 
"commit a revision that fails to compile." Which may or may not be 
acceptable in some environments but is, to me at least, a sign that 
something is inadequate in the version control system. I shouldn't be 
forced to have a broken build in my revision history just to be 100% 
certain my rename will be tracked accurately.

quoted text
> The only command I've found that doesn't do the "right thing" by default 
> is git-log and I think that once the following works, all the "why 
> doesn't git track renames" people will go quietly away:
>
>  $ git init
>  $ date > file1
>  $ git add file1
>  $ git commit -m ""
>  $ git mv file1 file2
>  $ git commit -m ""
>  $ git mv file2 file3
>  $ git commit -m ""
>  $ git log -- file3
>   

The following is actually my biggest beef with git's rename tracking, 
and it has nothing whatsoever to do with git-log (though I agree git-log 
needs to track renames too):

$ ls
dir1
$ ls dir1
file1 file2 file3
$ echo "#include file1" > dir1/file4
$ git add dir1/file4
$ git commit
$ git pull
$ ls
dir1 dir2
$ ls dir1
file4
$ ls dir2
file1 file2 file3

That's just plain broken in my opinion. One can perhaps contrive a test 
case or two where that's the desired behavior, but in the real world it 
is almost never what you actually want.

By the way, I don't think fixing that is necessarily related to how 
renames get detected, so in some sense it's a different bug report / 
feature request than the rename hints one. It would be possible to 
figure out the directory had been renamed based purely on content 
analysis; a bunch of files all individually renamed to the same places 
under a new directory, and a lack of any files at all left in the old 
one, probably means the directory got renamed. The content-based rename 
detector could handle this case.

-Steve
-
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