Re: [PATCH WIP 0/3] git log --exclude

From: Nguyen Thai Ngoc Duy <pclouds@gmail.com>
Date: Oct 7, 2011, 07:16 UTC
Message-ID: <CACsJy8DJs_cmCZegyPk=tB-bxWp4izrsTn8T=xeV1sU4fS5oTQ@mail.gmail.com>
In-Reply-To: <7vhb3n8ie9.fsf@alter.siamese.dyndns.org>

2011/10/6 Junio C Hamano <gitster@pobox.com>:

Show 14 quoted lines

> 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