Re: [ANNOUNCE] Git wiki

From: Jakub Narebski <jnareb@gmail.com>
Date: May 5, 2006, 16:47 UTC
Message-ID: <e3fvj2$779$1@sea.gmane.org>
In-Reply-To: <7vejz8241m.fsf@assigned-by-dhcp.cox.net>

Junio C Hamano wrote:

Show 17 quoted lines

> Petr Baudis <pasky@suse.cz> writes:
> 
>> But the non-obviously important part here to note is that the branch B
>> merely "corrects a typo on a comment somewhere" - the latest versions in
>> branch A and branch B are always compared for renames, therefore if
>> branch A renamed the file and branch B sums up to some larger-scale
>> changes in the file, it still won't be merged properly.
> 
> I probably am guilty of starting this misinformation, but the
> code does not compare the latest in A and B for rename
> detection; it compares (O, A) and (O, B).
> 
> But the end result is the same - what you say is correct.  If a
> path (say O to A) that renamed has too big a change, then no
> matter how small the changes are on the other path (O to B),
> rename detection can be fooled.  We could perhaps alleviate it
> by following the whole commit chain.

Or perhaps by helper information about renames, entered either by git-mv (and git-cp) or rename detection at commit, e.g. in the following form

        note at <commit-sha1> was-in <pathname>
        note at <commit-sha1> was-in <pathname>

(with the obvious limit of this "note header" solution is that it wouldn't work for filenames and directory name containing "\n"). I'm not sure if <pathname> should be just basename, of full pathname.

-- 
Jakub Narebski
Warsaw, Poland