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

From: Duy Nguyen <pclouds@gmail.com>
Date: Sep 17, 2013, 11:45 UTC
Message-ID: <CACsJy8AEoUUat-1smJ1BmDuDBLseWf8oZ+EJyuadSLncb1UMSw@mail.gmail.com>
In-Reply-To: <CAP8UFD1u9hPFcbftpacDFdp27Jmp0YLGbpHPP12uEtjzEmnPQA@mail.gmail.com>

On Tue, Sep 17, 2013 at 4:03 PM, Christian Couder <christian.couder@gmail.com> wrote:

Show 16 quoted lines

> On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Christian Couder <christian.couder@gmail.com> writes:
>>
>>> In practice though, as git bisect is a kind of binary search, if what
>>> you want to exclude is exclusively touched by half the commits, it
>>> will only add one more bisection step if you don't exclude it.
>>
>> Actually, I think the same remark would apply to any other Git command
>> that deal with a set of revisions. If you want to review code with "git
>> log -p", but you don't care about a subdirectory, you may want a "git
>> log -p --ignore-dir foo/" or so, too.
>
> Yeah, and there was a patch series about that 2 years ago:
>
> http://thread.gmane.org/gmane.comp.version-control.git/182830/

And that's just one of the few attempts if I remember correctly. I guess it's time revisit it. A few things to sort out before we get to the implementation:

Support flat or nested negation (i.e.include A, ignore A/B, but include A/B/C..). Nested thing complicates things so I'm towards the flat exclusion (exclude B means all inside B, no buts nor excepts) and probably cover most use cases

Interaction with "git grep --depth"

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

-- 
Duy