On Wed, Sep 18, 2013 at 12:02 AM, Junio C Hamano <gits...@pobox.com> 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.
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