Re: diffcore and directory renames

From: Yann Dirson <ydirson@altern.org>
Date: Sep 2, 2008, 20:48 UTC
Message-ID: <20080902204802.GS4985@nan92-1-81-57-214-146.fbx.proxad.net>
In-Reply-To: <7vfxojtr9t.fsf@gitster.siamese.dyndns.org>

On Mon, Sep 01, 2008 at 03:50:22PM -0700, Junio C Hamano wrote:

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

Wow, that's a great idea I did not think about :)

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

I am glad we're on the same side :)

Show 10 quoted lines

> > $ ./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.

Agreed.

Show 8 quoted lines

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

My idea was rather to just see tree/index/worktree as just 3 specialized forms of a single "abstract tree" of some sort, effectively unifying things.

But anyway afterwards I thought that there may be something for me to learn in how --find-copies-harder gets its information for non-modified sources of copies -- I'll have a look at that.

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

OK.

Best regards,

-- 
Yann