On Wed, Sep 18, 2013 at 12:02 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> 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. Implementation details leaked into the design thoughts. I was worried that the qsort() in pathspec() might make it incompatible with the :(exclude). Or I was thinking that --depth should be part of this new filter.. Never mind. >> 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. Under the hood, a new pathspec magic must be introduced (else we can't pass them from "git add -u" to git-add--interactive then some other commands that take pathspec). So --exclude would be transformed to the pathspec magic, similar to "git grep --depth". But we could add that later if :(exclude)something is too long to type. -- 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