On Fri, Feb 17, 2017 at 9:42 PM, Jeff King <peff@xxxxxxxx> wrote: > On Fri, Feb 17, 2017 at 02:50:23PM +0100, Ævar Arnfjörð Bjarmason wrote: > >> On Fri, Feb 17, 2017 at 9:23 AM, hIpPy <hippy2981@xxxxxxxxx> wrote: >> > Git has aliases for git commands. Is there a (an inbuilt) way to alias >> > options? If not, what is the reason? >> >> This has long been on my wishlist, because there's a lot of >> copy/pasted logic all over Git to make git foo --whatever aliased to >> foo.whatever in the config, but only for some options. >> >> It should ideally be part of something every option just supports, via >> the getopts struct. >> >> However, it can't allow you to modify whatever option you want, >> because some things like git-commit-tree should not be customized >> based on config, it would break things that rely on the plumbing >> commands. >> >> So it would have to be a whitelist for each option we allow to be >> configured like this via the getopts struct. >> >> Also there are surely other edge cases, like maybe the config option >> now doesn't 1=1 map to the name for the option in some cases, or the >> flag should be config-able but is has no long form (which we'd like >> for the config), then we'd want to add that etc. > > I think your idea is roughly equivalent in functionality to just > allowing aliases to override command names. E.g., anything you could do > with: > > [log] > follow = true > decorate = false > > could be done with: > > [alias] > log = "log --follow --no-decorate" Indeed, exact same thing, different syntax. Mostly I like this suggestion better, although the bad side of it is that it's not as easy to introspect with a dump of git-config -l. > The reason we have historically not allowed that is for the > "commit-tree" plumbing reason you gave above. One option would be to > relax it for a whitelist of porcelain commands. Then your whitelist at > least only has to cover commands, and not each individual option. > > I think there are a lot of corner cases in that whitelist, though. A lot > of commands serve dual porcelain/plumbing purposes. E.g., "log" and > "tag" are commonly used by both humans and by scripts. > > A first step in that direction would probably be an environment variable > to tell Git to suppress command-aliases. Scripts would set that to > ensure a more vanilla experience. It doesn't fix _existing_ scripts, but > if that option were introduced, then over time scripts would start to > use it. Then eventually it would be safe(r) to introduce something like > command aliases. The most gentle first step would be to try to turn the existing config options where you can override cli-options into some declarative thing from the current ad-hoc code we have for each one. That would be no change in behavior, but would make it easier to migrate more things in the future. Anyway, words are cheap. Just replied because to the extent that hIpPy wants to work on this I thought I'd sprinkle some historical caveats from memory. Other than that no point in keeping talking about this without patches.