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

Reply via email to