Re: [PATCH] Diff updates, fixing pathspec and rename/copy interaction.
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:41:58
quoted
quoted
quoted
quoted
"LT" == Linus Torvalds [off-list ref] writes:
LT> I would much prefer a _much_ simpler fix at least for the pathname part, LT> which is to just always require that pathspec handling is done _first_. LT> Why? Because that's fundamentally how git-diff-tree has to work, and it's LT> how my mental model has always been: the path limitations are a LT> first-order filter, and if you give a directory, the end result should LT> always look exactly as if that directory was a project of its own. Enlightment! My initial thinking was to do rename/copy first, deliberately ignoring pathspec (I was thinking about tweaking diff-tree to break out of its built-in pathspec limit to feed diffcore _everything_, even things outside of the specified directories when --detect-copies-harder is used), to cast a wider net so that it can come up with "the best matches". But what you just said made me realize that the definition of "the best matches" I had in mind was not best at all. I agree with you 100% that pathspec should come first before everything else to limit the world diffcore operates in, not just to limit the set of output paths. I still want to do what this patch does for another reason. It is so much simpler if I do not have to carry around _some_ unmatched pair after rename/copy. The earlier representation was forcing all the downstream diffcore filters to be aware of what rename/copy did, which was simply _wrong_. They should not have to care. About ordering of pickaxe and rename/copy, I think for most uses of diffcore filters, not limited to pickaxe, would make more sense if they come after rename/copy when rename/copy detection is in effect. What I really wanted to do (I made a side note comment in the earlier discussion about this, saying "something like streams", but have not pursued it further) is to make these diffcore filters/transformations stackable so that the main programs can control not just if each of them is used or not, but the order of application of the used ones. I cannot offhand think of a good use case of having pickaxe come _before_ rename/copy, but there may be a case the user want to have things in that order, and having the application order not hardcoded in three diff-* brothers is a major problem if we wanted to give that option.