On Tue, Nov 02, 2021 at 05:53:46PM +0100, Ævar Arnfjörð Bjarmason wrote: > The reason I suggested extending "git config" in [1] is because it seems > like a natural thing for "git config" to learn to spew out our idea of > default hardcoded config values to the user. > > But creating a variable form of that existing config just so we can have > "git var" spew it out just seems weird. > > We don't have or need such a variable now for anything else, so why go > through that indirection, instead of something that closes the feature > gap of asking what a config variable default is? To me, the point is that the user is not asking "what is the default value of this config variable?". They are asking "if I were to init a new repository, what would Git decide the default branch name is?". Right now that is very tied to the config mechanism (modulo the GIT_TEST_* bits, but I think we can ignore those for regular users), so those two are basically the same question. But it doesn't have to be. Abstracting it to the question the user actually wants to ask future-proofs the mechanism. I.e., I don't think introducing a new variable into "git var" is that big a deal. They don't have to be related to an environment variable; the documentation calls them "logical variables". This is exactly the kind of thing it's designed for. -Peff
