Re: [PATCH 1/2] status: really ignore config with --porcelain

Junio C Hamano [off-list ref] writes:

Matthieu Moy [off-list ref] writes:

quoted

quoted

Basically, having the CLI parser and the config parser flip two
different sets of variables, so we can discriminate who set what.
What annoys me is that this is the first instance of such a
requirement.

I don't think it's the first instance, but I can't remember precise
examples.

"First read config, override with command line" is what we always
do.  One recent workaround with selective exception I can think of
offhand is in diff config parser 6c374008 (diff_opt: track whether
flags have been set explicitly, 2013-05-10), but I am fairly sure
there are others.

That was the one I had in mind.

quoted

quoted

The approach I'm currently tilting towards is extending the
parse-options API to allow parsing one special option early.  I would
argue that this is a good feature that we should have asked for when
we saw 6758af89e (Merge branch 'jn/git-cmd-h-bypass-setup',
2010-12-10).  What do you think?

That's an option too, yes. But probably not easy to implement :-(.

Isn't it essentially your second option (running the CLI parser
before once, then read config, and then run the CLI parser for
real)?

Not really. The first run should be a kind of dry-run, except for the
--porcelain part.

In any case, I am still not convinced yet that status.short is a
real problem if --porcelain readers trip with "## branchname"
output.  Isn't it that the readers are broken and need fixing?

Before introducing status.short, scripts could call "git status
--porcelain" and get some output. They had no way to know whether
something would be added in the future. Now, they can run the same
command and get a different output. To me, that's exactly what we're
trying to avoid in plumbing.

The configuration file here is really meant for the user, not for
scripts. Scripts that want the branch information can use --branch.
Scripts that do not have absolutely nothing to gain in getting this
extra output (only extra parser complexity).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/