Re: RFC: git bisect should accept "paths-to-be-excluded"

From: Duy Nguyen <pclouds@gmail.com>
Date: Sep 18, 2013, 02:22 UTC
Message-ID: <CACsJy8CwtiJPLoFxts2NANH+i0ZoXcWSyS2qZC_zOx=WME2FkQ@mail.gmail.com>
In-Reply-To: <xmqqsix3z8ie.fsf@gitster.dls.corp.google.com>

On Wed, Sep 18, 2013 at 12:02 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 14 quoted lines

>> Interaction with "git grep --depth"
>
> I am not sure how that affects anything.  Conceptually, isn't
> "--depth" an independent axis to filter out paths that have too many
> components after given positive pathspec elements?  E.g. given
>
>         git grep --depth=2 pattern -- A B/C
>
> we will grab paths from two levels starting at A and B/C (so A/1/2
> and B/C/1/2 may hit but not A/1/2/3 nor B/C/1/2/3).  Shouldn't
> negative pathspecs just filter that depth filtering, i.e. if you
> have ":(exclude)*/1/*", even though both "A/1/2" and "A/a/b" may
> pass the --depth=2 filter, the former is excluded while the latter
> is not.

Implementation details leaked into the design thoughts. I was worried that the qsort() in pathspec() might make it incompatible with the :(exclude). Or I was thinking that --depth should be part of this new filter.. Never mind.

Show 8 quoted lines

>> Syntax. I guess --ignore (or --exclude) is more intuitive than
>> ":(exclude)something" but then it might collide with existing options
>> (I did not check if --ignore or --exclude is used anywhere though).
>> The latter also enables combining with other filters, such as
>> case-insensitive matching..
>
> I do not think it is an option to do this with any mechanism other
> than negative pathspecs.

Under the hood, a new pathspec magic must be introduced (else we can't pass them from "git add -u" to git-add--interactive then some other commands that take pathspec). So --exclude would be transformed to the pathspec magic, similar to "git grep --depth". But we could add that later if :(exclude)something is too long to type.

-- 
Duy