Duy Nguyen <pclouds@xxxxxxxxx> writes: > 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 Yeah, it is easy to say that git log -- A ':(exclude)A/B' A/B/C has two positive (A, A/B/C) and one negative (A/B), and then the most specific one A/B/C matches a path A/B/C/D and hence A/B/C/D is included. But to actually _design_ it, there are ambiguities that makes understanding and explaining the semantics, especially given pathspecs can have wildcards, icase matches, etc. For example, is ":(exclude,icase)A/B/?" more specific than "A/?/C" or less? So I tend to agree that we should aim for an easier to explain, if less capable, approach. > 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. > 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. -- 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