From: Nguyen Thai Ngoc Duy Date: Fri, 07 Oct 2011 07:16:04 GMT Subject: Re: [PATCH WIP 0/3] git log --exclude Message-ID: In-Reply-To: <7vhb3n8ie9.fsf@alter.siamese.dyndns.org> 2011/10/6 Junio C Hamano : > 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