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

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

 



Johannes Sixt <j.sixt@xxxxxxxxxxxxx> 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).
--
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]