Matthieu Moy <matthieu....@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
> I don't think it's the first instance, but I can't remember precise
"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. An older example is how show_notes_given is used
in the revision traversal machinery to conditionally set show_notes.
>> 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
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?
They should pick out what they care about and ignore the rest.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html