Re: Rename handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2007-03-19, Steven Grimm <koreth@xxxxxxxxxxxxx> wrote:
> 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

-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]