On Tue, Sep 17, 2013 at 4:03 PM, Christian Couder <christian.couder@xxxxxxxxx> wrote: > On Tue, Sep 17, 2013 at 10:21 AM, Matthieu Moy > <Matthieu.Moy@xxxxxxxxxxxxxxx> wrote: >> Christian Couder <christian.couder@xxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html