Do we have any other workflows that modify arcconfigs in place? This seems like it could be pretty fragile and state-destroying (in particular, this will totally blow away any commented-out lines in an arcconfig, right?)

Today, arcconfig files are JSON and won't parse if you have comments:

$ arc branch
 Exception 
Unable to parse '.arcconfig' file '/Users/epriestley/dev/core/lib/phabricator/.arcconfig'.
Parse error on line 1 at column 1: Expected one of: 'STRING', '}'
(Run with `--trace` for a full exception trace.)

Rewriting these files could still destroy formatting (if you indent things in a special way, or group keys together with blocks of newlines between them) or (possibly) change key ordering in JSON dictionaries (although I think we'll always retain it, today).

This code also isn't actually touching what's on disk (yet): we just pretend what's on disk is different from what's actually there while reading it, for now.

Later in this series, we do start writing to .arcrc via arc alias (and, somewhat later, via arc set-config). However, these commands have always rewritten ~/.arcrc. Specifically, it is completely rewritten on master by: arc alias, arc set-config, and arc install-certificate.

The "local" config file (usually path/to/project/.git/arc/config or similar) is also rewritten today by arc set-config --local ....

I currently expect to mostly retain these behaviors (so we should be in the same place after these changes as before). However, there's some argument for possibly trying to rewrite other files (/etc/arcconfig, path/to/project/.arcconfig), and/or for providing flags to arc set-config to let you interact with them, e.g. arc set-config --system ... and arc set-config --project .... This doesn't need to happen as part of this phase, though, I think. Some config format stuff is changing, but for now we can transparently read the old versions of things.