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 >> 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. 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 real)? 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
