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

From: Junio C Hamano <gitster@pobox.com>
Date: Oct 7, 2011, 17:57 UTC
Message-ID: <7vaa9cwup2.fsf@alter.siamese.dyndns.org>
In-Reply-To: <CACsJy8DJs_cmCZegyPk=tB-bxWp4izrsTn8T=xeV1sU4fS5oTQ@mail.gmail.com>

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

> 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.

I tend to think it probably is acceptable solution to define "struct pathspec" to have one positive and one negative set, traversing and declaring a match on what matches something from the positive set only if it does not match anything in the negative set.

That is similar to how we define revision ranges in the sense that the range notation to have two ranges (A..B C..D) does not mean union of two sets (A..B + C..D), but is difference between two unions ((B D)-(A C)).

> 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".

And if you define "struct pathspec" to have one positive and one negative set, you do not have to limit narrow clone only to positive. The repository specific narrow pathspec will have one such "struct pathspec", but the user may give us from the command line another "struct pathspec". At runtime, we would merge them to form into one negative and one positive set, and apply the same rule: nothing that matches any negative will appear in the traversal or in the output.