Re: [PATCH nd/attr-match-optim-more 2/2] attr: more matching optimizations from .gitignore
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Oct 9, 2012, 16:40 UTC
- Message-ID
- <7vhaq3ha4r.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <7vvcekgn0h.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 35 quoted lines
> Johannes Sixt <j.sixt@viscovery.net> writes: > >> Am 10/9/2012 7:08, schrieb Junio C Hamano: >>> Imagine if we allowed only one attribute per line, instead of >>> multiple attributes on one line. >>> >>> - If you want to unset the attribute, you would write "path -attr". >>> >>> - If you want to reset the attribute to unspecified, you would >>> write "path !attr". >>> >>> Both are used in conjunction with some other (typically more >>> generic) pattern that sets, sets to a value, and/or unsets the >>> attribute, to countermand its effect. >>> >>> If you were to allow "!path attr", what does it mean? It obviously >>> is not about setting the attr to true or to a string value, but is >>> it countermanding an earlier set and telling us to unset the attr, >>> or make the attr unspecified? >> >> If I have at the toplevel: >> >> *.txt whitespace=tabwidth=4 >> >> and in a subdirectory >> >> *.txt whitespace=tabwidth=8 >> !README.txt >> >> it could be interpreted as "do not apply *.txt to REAME.txt in this >> subdirectory". That is, it does not countermand some _particular_ >> attribute setting, but says "use the attributes collected elsewhere". > > It makes it unclear what "elsewhere" means, though (besides, it does > not match the way the matching logic works at all).
Ignoring the current implementation, I find the suggested semantics somewhat intriguing. It is something we may want to look into in the future.