On Thu, Jan 9, 2020 at 2:14 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > "Matthew Rogers via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > > > From: Matthew Rogers <mattr94@xxxxxxxxx> > > > > CONFIG_SCOPE_CMDLINE is generally used in the code to refer to config > > values passed in via the -c option. This is a little bit too specific > > as there are other methods to pass config values so that the last for a > > single command (namely --file and --blob). > > Sorry, but I cannot parse this, especially around "so that the last > for ..." part. > My bad, I guess I must have not read as carefully as I thought I did. It should read: "... there are other methods to pass config values so that _they_ last for a single command ..." > > As the "visibility" of config > > values passed by these situations is common, we unify them as having a > > scope of "command" rather than "command line". > > Is the "unification" something done by this patch? It does not > appear to be so. The existing code already was using CMDLINE to > call "git -c VAR=VAL" and also something else (which is not clear to > me, unfortunately, probably because I failed to parse the above > X-<), and this step renames CMDLINE to COMMAND perhaps because > CMDLINE has too strong connotation with the "-c" thing and much less > with the other thing (which is not clear to me, unfortunately) and > you found that renaming it to COMMAND would cover both cases better? Essentially, the "unification" was referring to more the unification of all the things that affect configuration only for the duration of a specific command. The gist of this patch was to say "There are a few ways besides -c to pass a configuration option that lasts for a single command, so it makes sense to broaden that scope.". The change is definitely justified in that COMMAND communicates that much clearer than CMDLINE as REPO, GLOBAL, SYSTEM all describe the thing that can see the configuration options, and it's specifically the command the can see the -c options and not the command line as a whole. > > I also do not get what you meant by "visibility", but it probably is > primarily because it is not clear what "the other thing" is. I was using visibility as another way to conceptualize scoping. A scope more or less determines who can "see" a thing, so maybe that language was a little bit too much in my head. The issue is that currently the code doesn't care about any of that (as only -c options actually have COMMAND scoping), so maybe I should roll it into the next patch of the series? As that introduces code that actually cares about the difference?
