Re: [PATCH 0/6] Introduce pathspec struct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2010/9/28 Junio C Hamano <gitster@xxxxxxxxx>:
> Just a couple of quick notes.
>
> Â- I had to eject Bo's "log -L range path" series in order to push this
> Â out on 'pu' as the range stuff adds new callsites to the old pathspec
> Â API.
>
> Â This is tentative and does not mean Bo's series is getting rejected;
> Â I'd want to get its command line parsing around the pathnames fixed
> Â anyway but I suspect the affected codepath would overlap between the
> Â two series. ÂHelp is appreciated.

I'll have a look.

> Â- I do not think either !pattern nor ^pattern is particularly a good way
> Â to express negative pathspecs. ÂMy gut feeling is (I have not thought
> Â this through nor clearly enough; note the time of this message) that it
> Â would be the cleanest at the UI level to introduce negative patterns as
> Â arguments to a separate command line flag, e.g.
>
> Â $ git log --exclude "Doc*" master..pu -- '*.txt'
> Â $ git grep --exclude "t/" -e 'test .*-L' -- '*.sh'

I was writing "but you would lose the ability to mix negative and
positive pathspecs together, something like 'exclude Documentation
except Documentation/technical'", but then we can have negative
excludes too:

$ git log --exclude Documentation --exclude "!Documentation/technical"
master..pu -- '*.txt'

does not sound too twisted to understand (I hope).

> Â- David's "git grep --exclude-dir D" topic should be able to internally
> Â use the same negative pathspec mechanism. ÂAt the command line level,
> Â it allows (and needs to allow) only the leading prefix (which is how
> Â GNU grep's --exclude-dir works), but it makes tons of sense for us to
> Â allow "--exclude $pattern" from the command line, and share the
> Â mechanism internally between the two.

Yes, eventually. But
 - tree_entry_interesting() needs (a bit complex) rework to have
wildcard matching capability
 - then I am still not sure how negative pathspecs should be done properly

Both may take me weeks to come up with something sensible. If David
needs "git grep --exclude-dir" now, he should keep working on
builtin/grep.c as he's doing now (maybe change --exclude-dir to
--exclude). If my work on negative pathspec has a result, sure I will
remove pathspec_matches() from builtin/grep.c, but his work on the
command line interface _and tests_ won't be wasted.
-- 
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]