On Thu, Dec 04, 2014 at 11:02:37AM -0800, Junio C Hamano wrote: > > Christian raised the issue of cluttering the "git --option" namespace, > > and I do agree that's a potential issue. > > I am not sure if that is an issue at all. You will need the same > number of options to cover all the necessary "computables" somewhere > anyway. > > "git --show-this-or-that-computable" is not more or not less > cluttering compared to "git var --show-this-or-that-computable". My issue is only that "git --foo" has other options besides computables. So you need to name each option in a way that makes it clear it is reporting a computable and not doing something else. Take "git --pager" for instance. That would be a natural choice to replace "git var GIT_PAGER". But shouldn't "--pager" be the opposite of the existing "--no-pager"? So instead we probably need some namespace to indicate that it is a "showing" option. Like "--show-pager". And then for consistency, we would probably want to move "--exec-path" to "--show-exec-path", creating a new "--show-" namespace. Or we could call that namespace "git var". :) > I understand we are not talking about removing "git --exec-path", > but the desire is to have one single command the user can go to ask > about all the computables. If "var" is to become that single > command, then we need to keep the interface to it uniform and > consistent, and telling the users to use "git var GIT_PAGER" and > "git var --exec-path" in the same script will not fly well. Also > these GIT_$COMPUTABLE_NAME appear as if they can be influenced by > setting environment variables of the same name, which invites > further confusion. This is especially bad because some of then do > get affected by environment (i.e. GIT_EDITOR="vi" has effect, but > GIT_AUTHOR_IDENT="Gitster <gitster@xxxxxxxxx>" does not). I do not think "git var --exec-path" is a good idea, nor GIT_EXEC_PATH for the environment-variable confusion you mentioned. I was thinking of just creating a new namespace, like: git var exec-path git var author-ident and deprecating the 4 existing GIT_* variables. > If we admit that "git var" was a failed experiment that gained only > four fake variables for the past 10 years, it will not be too much > trouble and transition pain to turn the existing ones into option > form, like --author-ident etc., like your original proposal did, I > would think. I am also OK with that, if the details turn out to be not too ugly once somebody starts digging in. I was just anticipating some ugliness in advance. :) But I am not planning to work on it in the immediate future, so whoever does can make that call. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html