Re: Rename handling

["Martin Langhoff" <martin.langhoff@gmail.com>]

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?

> 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