Re: diffcore and directory renames

[Junio C Hamano <gitster@pobox.com>]

Yann Dirson <ydirson@altern.org> writes:

> I often found myself lost when looking at a diff where a couple of
> large dirs where renamed, and a handful of files were modified to take
> the rename into account - not a rare situation, I'd say.  In such a
> case, the diffs themselves are mostly hidden among numerous rename
> entries.

Yes, I've hinted here number of times that rename detection could notice
the fact that neighbouring paths are migrating to the same directory and
boost similarity scores of leftover paths that did not otherwise made the
threshold in such a situation.

I am glad to see finally somebody got interested ;-)

> $ ./git-diff-tree 0f1027 -M
> 0f1027e1aceb4bc5fa682776ab9f72935e2cd1b3
> :040000 040000 6f6159f0245784352414ff38ffb68bae80f30bd6 6f6159f0245784352414ff38ffb68bae80f30bd6 R100   ppc     moved

Yes, diff-tree can show this, and you should be able to teach diff-index
with a clean cache-tree to do similar, but this only applies to the
non-recursive 100% rename at the toplevel, which is too narrow a special
case to be interesting at all.  We perhaps further could run the
similarity comparison on the raw tree objects if we wanted to so that you
can find inexact matches, but I think it is going in the wrong direction.

The thing is, diffcore is designed to be a general mechanism to unify
comparisons on two arbitrary sets of files, be they from tree-vs-tree,
tree-vs-index, tree-vs-worktree, or index-vs-worktree.  The machinery
should be able to operate on any two sets of files in the same way and
produce more-or-less the same results.  It is Ok for callers to give extra
hints, when available, to speed up the computation, but the core of the
algorithm should not depend on the presense of such hints to deduce the
renames.

So please aim to make the hint-less case, "diff-files --no-index", produce
a sensible result.  That should be the first step.