Re: Rename handling

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 21, 2007, 23:01 UTC
Message-ID: <Pine.LNX.4.63.0703212341020.22628@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <4601B199.9060300@midwinter.com>

Hi,

On Wed, 21 Mar 2007, Steven Grimm wrote:

Show 11 quoted lines

> 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...
> 
> 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!"

No. That's not the argument. The argument goes like this:

	Whatever solutions you choose to handle renames, it _will_ have 
	problems. We chose a solution which appears to have the least
	problems.

Show 8 quoted lines

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

That is a particularly bad example: you are not renaming files in that example!

Show 5 quoted lines

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

Not at all. You are actually recording the rename. So, you proved that you do have a method to record a rename manually.

Show 8 quoted lines

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

Hey, I might be wrong. Why don't you prove me wrong? Code talks.

Ciao, Dscho