Re: Rename handling

From: John Goerzen <jgoerzen@complete.org>
Date: Mar 19, 2007, 19:49 UTC
Message-ID: <slrnevtqaq.1df.jgoerzen@katherina.lan.complete.org>
In-Reply-To: <45FED31B.8070307@midwinter.com>

On 2007-03-19, Steven Grimm <koreth@midwinter.com> wrote:

Show 11 quoted lines

> John Goerzen wrote:
>> 2) For me, a rename is a logical change to the source tree that I want
>>    to be recorded with absolute certainty, not guessed about later.
>>    Sometimes I may make API changes and it is useful to see how module
>>    names changed, with complete precision, later.  I do not want to be
>>    victim to an incorrect guess, which could be possible.
>>   
>
> If you commit your renames separately from your content changes, it'll 
> be unambiguous and you won't have to worry about it. That's what I 
> usually do when this is a concern and it has yet to break for me.

As I have been testing Mercurial and its addremove feature (which does basically what Git is doing), I encountered some situations where this broke, sometimes spectacularly. This generally happened when there were identical files in the source tree, or when there were identical resulting files, or 0-byte files (the extreme pathological case, of course).

Again, sometimes filenames have significance. The presence or absence of 0-byte files can impact what make does, for instance. Not that I advocate for this behavior, but just pointing out that it exists.

I understand what Linus is saying about applying patches from others and agree that what git is doing is nice in this case.

But if most of my work is hacking directly on the code, I am going to know better than the VCS what is being renamed, and would like to record that. Sometimes the filenames are part of the code.

I want the option.

-- John