C. Michael Pilato wrote:
> On 11/06/2012 10:29 AM, Julian Foad wrote:
>>>> Sorry, that section is out of date, I corrected it. The
>>>> --no-ignores option still works for status, it's only for
>>>> import and add that it can't be overridden.
>>>
>>> Perfect, thanks. I think not-overriding for add/import is fine: for
>>> 'import' only the repository files are affected, and for 'add' files
>>> matching the pattern can be specified explicitly in the argv targets
>>> (and auto-props added can be modified or stripped after 'add' and
>>> before 'commit').
>>
>> Am I the only one going "Eww!" on reading this?
>>
>> We have three ways of specifying ignores, and we have an option that
>> disregards them, only in one cammand it disregards all of the ways and in
>> two other commands the option only disregards two of the ways. And we
>> say "sure, that sounds perfect". It doesn't sound fine to me, it sounds
>> horrible.
>
> I would be in favor of --no-ignores working identically across all the
> subcommands. I understand the arguments for "add" and
> "import" not allowing
> the override, so I don't fault Paul for choosing the current arrangement.
Oh, I don't recall such arguments. I was particularly baffled because what was written above in this thread seemed to assume that the need for inconsistency is self-evident.
> But I've not been a huge fan of the idea of "server-dictated
> configuration" anyway, being more in favor of "repos-default
> configuration" or somesuch that doesn't pretend to be the
> final word on anything. With or without this feature in place,
> enforcement of ignores (and auto-props, for that matter) can
> only happen in the hook scripts, anyway, so I don't see the harm in
> allowing a user to specify --no-ignores if his or her admin doesn't
> care enough to enforce that the default configuration is honored.
Right, +1 there.
- Julian
Received on 2012-11-06 17:20:38 CET