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

[Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>]

Junio C Hamano <gitster@pobox.com> writes:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
>
>>> 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.

>>> 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/