Re: Rename handling

From: Martin Langhoff <martin.langhoff@gmail.com>
Date: Mar 22, 2007, 02:39 UTC
Message-ID: <46a038f90703211939j15dbda4cpfa2f49229b8c16cb@mail.gmail.com>
In-Reply-To: <200703220301.41180.jnareb@gmail.com>

On 3/22/07, Jakub Narebski <jnareb@gmail.com> wrote:

Show 12 quoted lines

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

> Still, it would be nice to have --follow=<file> option to git-log family,
> besides path limiting.

+1 here - git log should have something equivalent to diff's -M. When the file "disappears", run a diff-tree -M -C against the parents to see whether there were any "related predecessors" to the file to add to the pathspec. Of course, there could be more than one.

For example, right now, git log git-cvsimport.perl ends at the big tool rename.

cheers,

martin