Re: Rename handling

[Steven Grimm <koreth@midwinter.com>]

Johannes Schindelin wrote:
> P.S.: It would be so nice if somebody (preferably someone who previously 
> thought manual renames were a pretty clever thing) to write up the 
> arguments, and add that to the "why automatic renaming?" section of the 
> FAQ...
>   

I completely understand the arguments in favor of automatic renaming. I 
have never once advocated getting rid of it. It is useful and valuable 
and works well within its constraints.

For some reason whenever I try to argue that we need, IN ADDITION to the 
automatic rename detection, a way to provide hints to the merge engine 
that a non-auto-detectable rename has occurred, the responses I get back 
are mostly of the form, "But the automatic rename detection handles all 
these cases that wouldn't be handled with manual rename marking!" It's 
as if one can either think autodetection is a good idea, or manual 
flagging is a good idea, but under no circumstances could they both be 
good ideas at the same time. (As evidenced by the comment above about 
"someone who previously thought manual renames were a pretty clever 
thing.") But they are not in fact mutually exclusive.

Say you're tracking a directory full of video files. Even a slight tweak 
to one of them (to put a logo in the corner, say, while moving it into 
an "accessible by the public" directory) will result in a file that has 
no content in common at all if you look at it as purely a stream of 
bytes. Short of decoding the thing to video frames and looking for 
similarities in the images, there's no way any merge tool will ever be 
able to tell the two versions are the same file unless the user 
indicates it. Any tool that saves its files in compressed form will have 
a similar problem: unless git knows how to uncompress the tool's files, 
a content comparison will often be useless to detect similarities.

Of course, git actually does give you a way to mark renames manually: 
commit them by themselves without changing the content. The problem is 
that that overloads the "record this snapshot of the tree for posterity" 
command purely for the purpose of working around the merge tool's 
inability to detect the rename. If other people are like me, when they 
record a rename-only commit immediately followed by a content-change 
commit on the same files, the intermediate state of the tree (with just 
the renames) is not actually an interesting point in the history of the 
project. It's not a revision in anything but an internal git sense. It 
probably doesn't even compile or work correctly. It exists only because 
I'm forced to create it if I want to be 100% certain my renames will be 
tracked accurately. It is, in short, pollution in the history of my project.

It also means that if I want reliable renames, I can no longer impose 
the requirement that my project be in a buildable state at each commit. 
That doesn't seem like all that unreasonable a thing to want (but maybe 
it is?) -- I don't want to be in the situation where I say, e.g. "git 
checkout -b testbranch '@{1 day ago}'" and get a broken working copy 
because I happened to do it at just the wrong time of day. But with the 
"just commit your renames separately" approach, that's exactly what can 
happen.

Now, once again, none of the above is an argument against the automatic 
rename detection. For cases where renames are automatically detectable, 
it works fine and will continue to do so, and in fact doesn't have the 
problem of committing broken builds. I am not arguing it should be 
replaced or that the user should be required to tell git about every 
rename. But the lack of an additional manual option forces me into a 
particular workflow that I wouldn't otherwise use and prevents me from 
imposing the workflow rules I *do* want.

Hopefully that shed a little light on why I think manual rename support 
is not a totally idiotic idea.

-Steve