Andy Parkins wrote:
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.
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html