Re: Rename handling

[Jakub Narebski <jnareb@gmail.com>]

Martin Langhoff wrote:
> On 3/22/07, Jakub Narebski <jnareb@gmail.com> wrote:
>> Additional issue that we have to think about with respect to rename
>> support for merges is that git uses 3-way merge, taking into account
>> _only_ upstream commit (of the branch we want to merge to), side branch
>> commit (of the branch we want to merge) and common ancestor[*1*]
>> (merge base) for merging. What is important is that the intermediate
>> states, how we got to the current state, does not matter.
>>
>> Well, one could argue that if we remember explicit (provided by user)
>> info about renames for example in proposed 'note' field of a commit
>> object, or in other helper structure (we cannot remember the information
>> in blob or tree), we can gather and remember information about recorded
>> explicit renames when finding common ancestor...
> 
> But we do have some of that already - if one trees being merged is
> missing a path that changed on the other one, we walk back on the
> ancestry looking for renames.
> 
> Or am I seeing things?

First, I was talking about hypotetical manually-provided helper information
about explicit renames, entered by user, not guessed by SCM.

Second, I have thought that rename detection is done on final states: upstream,
branch and ancestor, not on intermediate commits. I guess I thought wrong.
 
-- 
Jakub Narebski
Poland