Re: [PATCH nd/attr-match-optim-more 2/2] attr: more matching optimizations from .gitignore

Junio C Hamano [off-list ref] writes:

Johannes Sixt [off-list ref] writes:

quoted

Am 10/9/2012 7:08, schrieb Junio C Hamano:

quoted

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.