Re: Rename handling
- From
Steven Grimm <koreth@midwinter.com>
- Date
- Mar 19, 2007, 19:21 UTC
- Message-ID
- <45FEE2B2.6050904@midwinter.com>
- In-Reply-To
- <200703191903.20005.andyparkins@gmail.com>
Andy Parkins wrote:
Show 6 quoted lines
> 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.
Show 14 quoted lines
> 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