2011/10/6 Junio C Hamano <gitster@xxxxxxxxx>: > For the purpose of "log --exclude" [*2*], I do not mind too much if the UI > expressed negative pathspecs using such a new command line option, but I > think it would be more natural to say (notations aside): > > $ git log -- ':(no):po' . > > and define the behaviour of user-supplied pathspec limiter this way: > > * Paths are matched from left to right; > > * First match determines the fate of the path; > > * A match with negative pathspec means "the path in question does _not_ > match". Things have changed a bit since last time I touched negative pathspec. Because of depth limit support [1], pathspecs have to be sorted, which means we cannot keep pathspec in original order to match from left to right. There may be a solution to mix depth limit and negative pathspec. I haven't thought carefully about that because I lean towards a simpler behaviour that only allows one negation level: a file is in if it matches any positive pathspecs and none of negative ones. This is enough if narrow clones consist of positive pathspec only. I really doubt if users would want to make a narrow clone that "contains A but not A/B, storage-wise". [1] 86e4ca6 (tree_entry_interesting(): fix depth limit with overlapping pathspecs) -- Duy -- 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