D219: morestatus: move fb extension to core as '--repo-state' option to status

martinvonz (Martin von Zweigbergk) phabricator at mercurial-scm.org
Fri Aug 4 13:16:54 EDT 2017


martinvonz added a comment.


  In https://phab.mercurial-scm.org/D219#3661, @quark wrote:
  
  > I'm thinking about the difference between the deprecated `[defaults]` and `[commands]` (and also `[alias]`) but don't quite get it. It seems people wanting the behavior might just set `alias.status = status -v`, or use `[defaults]`. What's the advantage of using a `[commands]` option?
  
  
  Good point, there's probably no good reason to use [commands] for this. [defaults] has been discouraged, but I don't know if there's a good reason to discourage it (I think it's already ignored when HGPLAIN is in effect). [commands] make sense when there's no command line flag for the behavior, but we do have that here. So if we agree on using --verbose for this, I don't think I see a reason to a special config for it and we can use [defaults] instead.
  
  Hmm, I just realized there is a somewhat good reason to avoid [defaults]: it applies to *all* options at once. Let me clarify with an example. Let's say your sysadmin has set "defaults.status = --relative" (hypothetical option -- it's currently a config in [commands]) and you want to keep that *and* get verbose status output, you now have to copy the default config from the system hgrc. I don't think I've heard that argument against [defaults] before, but that seems more relevant than the scripting argument (which, again, goes away with HGPLAIN). Or am I mistaken?

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D219

To: pulkit, #hg-reviewers
Cc: quark, akushner, martinvonz, durham, mercurial-devel


More information about the Mercurial-devel mailing list