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
