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 :) > > $ ./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. > 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
