From: Duy Nguyen Date: Tue, 17 Sep 2013 11:45:00 GMT Subject: Re: RFC: git bisect should accept "paths-to-be-excluded" Message-ID: In-Reply-To: On Tue, Sep 17, 2013 at 4:03 PM, Christian Couder wrote: > On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy > wrote: >> Christian Couder 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