{"thread":{"id":"45160","subject":"git alias for options","startedAt":"2017-02-17T08:24:20Z","lastAt":"2017-02-18T06:33:53Z","messageCount":9,"participants":["hIpPy","Michael J Gruber","Ævar Arnfjörð Bjarmason","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"311848","messageId":"CAM_JFCz+9mxp37BTT7XPJ0fMd41DdbAxnvQF7id9msH+SDe6_Q@mail.gmail.com","threadId":"45160","inReplyTo":null,"subject":"git alias for options","fromName":"hIpPy","fromEmail":"hippy2981@gmail.com","sentAt":"2017-02-17T08:23:24Z","receivedAt":"2017-02-17T08:24:20Z","isPatch":false,"sender":{"key":"hippy2981@gmail.com","avatar":"https://gravatar.com/avatar/00812eff6e91f90d2c1fe2faccef22d7c475073a1f5b7467152d5174fa61e0cb?d=mp&s=160"},"body":"Git has aliases for git commands. Is there a (an inbuilt) way to alias\noptions? If not, what is the reason?\n\nThanks,\nhippy\n"},{"id":"311859","messageId":"e6b3b3fa-2993-2850-a682-c58312a8385c@drmicha.warpmail.net","threadId":"45160","inReplyTo":"CAM_JFCz+9mxp37BTT7XPJ0fMd41DdbAxnvQF7id9msH+SDe6_Q@mail.gmail.com","subject":"Re: git alias for options","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2017-02-17T13:15:49Z","receivedAt":"2017-02-17T13:16:02Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"hIpPy venit, vidit, dixit 17.02.2017 09:23:\n> Git has aliases for git commands. Is there a (an inbuilt) way to alias\n> options? If not, what is the reason?\n> \n> Thanks,\n> hippy\n> \n\nYou can setup an alias for \"command with options\", for example:\n\ngit help s\n`git s' is aliased to `status -s -b -uno .'\n\nAs you see here, this can include non-option arguments such as the\npathsepc '.'.\n\nYou cannot alias options independent of the command, though.\n\nMichael\n"},{"id":"311861","messageId":"CACBZZX4Zmwb8ZHGBXCpm6=yH_uxc-K1X1vv1jQ+wwnUPneqM4A@mail.gmail.com","threadId":"45160","inReplyTo":"CAM_JFCz+9mxp37BTT7XPJ0fMd41DdbAxnvQF7id9msH+SDe6_Q@mail.gmail.com","subject":"Re: git alias for options","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-02-17T13:50:23Z","receivedAt":"2017-02-17T13:50:49Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Feb 17, 2017 at 9:23 AM, hIpPy wrote:\n> Git has aliases for git commands. Is there a (an inbuilt) way to alias\n> options? If not, what is the reason?\n\nThis has long been on my wishlist, because there's a lot of\ncopy/pasted logic all over Git to make git foo --whatever aliased to\nfoo.whatever in the config, but only for some options.\n\nIt should ideally be part of something every option just supports, via\nthe getopts struct.\n\nHowever, it can't allow you to modify whatever option you want,\nbecause some things like git-commit-tree should not be customized\nbased on config, it would break things that rely on the plumbing\ncommands.\n\nSo it would have to be a whitelist for each option we allow to be\nconfigured like this via the getopts struct.\n\nAlso there are surely other edge cases, like maybe the config option\nnow doesn't 1=1 map to the name for the option in some cases, or the\nflag should be config-able but is has no long form (which we'd like\nfor the config), then we'd want to add that etc.\n"},{"id":"311932","messageId":"20170217204227.kreormjoo5lr6zu4@sigill.intra.peff.net","threadId":"45160","inReplyTo":"CACBZZX4Zmwb8ZHGBXCpm6=yH_uxc-K1X1vv1jQ+wwnUPneqM4A@mail.gmail.com","subject":"Re: git alias for options","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-17T20:42:27Z","receivedAt":"2017-02-17T20:42:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 17, 2017 at 02:50:23PM +0100, Ævar Arnfjörð Bjarmason wrote:\n\n> On Fri, Feb 17, 2017 at 9:23 AM, hIpPy wrote:\n> > Git has aliases for git commands. Is there a (an inbuilt) way to alias\n> > options? If not, what is the reason?\n> \n> This has long been on my wishlist, because there's a lot of\n> copy/pasted logic all over Git to make git foo --whatever aliased to\n> foo.whatever in the config, but only for some options.\n> \n> It should ideally be part of something every option just supports, via\n> the getopts struct.\n> \n> However, it can't allow you to modify whatever option you want,\n> because some things like git-commit-tree should not be customized\n> based on config, it would break things that rely on the plumbing\n> commands.\n> \n> So it would have to be a whitelist for each option we allow to be\n> configured like this via the getopts struct.\n> \n> Also there are surely other edge cases, like maybe the config option\n> now doesn't 1=1 map to the name for the option in some cases, or the\n> flag should be config-able but is has no long form (which we'd like\n> for the config), then we'd want to add that etc.\n\nI think your idea is roughly equivalent in functionality to just\nallowing aliases to override command names. E.g., anything you could do\nwith:\n\n [log]\n follow = true\n decorate = false\n\ncould be done with:\n\n [alias]\n log = \"log --follow --no-decorate\"\n\nThe reason we have historically not allowed that is for the\n\"commit-tree\" plumbing reason you gave above. One option would be to\nrelax it for a whitelist of porcelain commands. Then your whitelist at\nleast only has to cover commands, and not each individual option.\n\nI think there are a lot of corner cases in that whitelist, though. A lot\nof commands serve dual porcelain/plumbing purposes. E.g., \"log\" and\n\"tag\" are commonly used by both humans and by scripts.\n\nA first step in that direction would probably be an environment variable\nto tell Git to suppress command-aliases. Scripts would set that to\nensure a more vanilla experience. It doesn't fix _existing_ scripts, but\nif that option were introduced, then over time scripts would start to\nuse it. Then eventually it would be safe(r) to introduce something like\ncommand aliases.\n\nBut nobody has ever taken that first step, so here we are.\n\n-Peff\n"},{"id":"311946","messageId":"20170217221317.e5kby2jwutdznnlk@sigill.intra.peff.net","threadId":"45160","inReplyTo":"CACBZZX7nJkRmSxTdvhgXz5Zuk0KeovSZM1D_eGqbBn7i20+ePQ@mail.gmail.com","subject":"Re: git alias for options","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-17T22:13:17Z","receivedAt":"2017-02-17T22:13:24Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 17, 2017 at 11:10:08PM +0100, Ævar Arnfjörð Bjarmason wrote:\n\n> > A first step in that direction would probably be an environment variable\n> > to tell Git to suppress command-aliases. Scripts would set that to\n> > ensure a more vanilla experience. It doesn't fix _existing_ scripts, but\n> > if that option were introduced, then over time scripts would start to\n> > use it. Then eventually it would be safe(r) to introduce something like\n> > command aliases.\n> \n> The most gentle first step would be to try to turn the existing config\n> options where you can override cli-options into some declarative thing\n> from the current ad-hoc code we have for each one.\n> \n> That would be no change in behavior, but would make it easier to\n> migrate more things in the future.\n\nYeah, I'd agree with that. It does not change anything for the users,\nbut it makes the implementation less annoying.\n\n-Peff\n"},{"id":"311949","messageId":"CACBZZX7nJkRmSxTdvhgXz5Zuk0KeovSZM1D_eGqbBn7i20+ePQ@mail.gmail.com","threadId":"45160","inReplyTo":"20170217204227.kreormjoo5lr6zu4@sigill.intra.peff.net","subject":"Re: git alias for options","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-02-17T22:10:08Z","receivedAt":"2017-02-17T22:18:59Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Fri, Feb 17, 2017 at 9:42 PM, Jeff King wrote:\n> On Fri, Feb 17, 2017 at 02:50:23PM +0100, Ævar Arnfjörð Bjarmason wrote:\n>\n>> On Fri, Feb 17, 2017 at 9:23 AM, hIpPy wrote:\n>> > Git has aliases for git commands. Is there a (an inbuilt) way to alias\n>> > options? If not, what is the reason?\n>>\n>> This has long been on my wishlist, because there's a lot of\n>> copy/pasted logic all over Git to make git foo --whatever aliased to\n>> foo.whatever in the config, but only for some options.\n>>\n>> It should ideally be part of something every option just supports, via\n>> the getopts struct.\n>>\n>> However, it can't allow you to modify whatever option you want,\n>> because some things like git-commit-tree should not be customized\n>> based on config, it would break things that rely on the plumbing\n>> commands.\n>>\n>> So it would have to be a whitelist for each option we allow to be\n>> configured like this via the getopts struct.\n>>\n>> Also there are surely other edge cases, like maybe the config option\n>> now doesn't 1=1 map to the name for the option in some cases, or the\n>> flag should be config-able but is has no long form (which we'd like\n>> for the config), then we'd want to add that etc.\n>\n> I think your idea is roughly equivalent in functionality to just\n> allowing aliases to override command names. E.g., anything you could do\n> with:\n>\n> [log]\n> follow = true\n> decorate = false\n>\n> could be done with:\n>\n> [alias]\n> log = \"log --follow --no-decorate\"\n\nIndeed, exact same thing, different syntax. Mostly I like this\nsuggestion better, although the bad side of it is that it's not as\neasy to introspect with a dump of git-config -l.\n\n> The reason we have historically not allowed that is for the\n> \"commit-tree\" plumbing reason you gave above. One option would be to\n> relax it for a whitelist of porcelain commands. Then your whitelist at\n> least only has to cover commands, and not each individual option.\n>\n> I think there are a lot of corner cases in that whitelist, though. A lot\n> of commands serve dual porcelain/plumbing purposes. E.g., \"log\" and\n> \"tag\" are commonly used by both humans and by scripts.\n>\n> A first step in that direction would probably be an environment variable\n> to tell Git to suppress command-aliases. Scripts would set that to\n> ensure a more vanilla experience. It doesn't fix _existing_ scripts, but\n> if that option were introduced, then over time scripts would start to\n> use it. Then eventually it would be safe(r) to introduce something like\n> command aliases.\n\nThe most gentle first step would be to try to turn the existing config\noptions where you can override cli-options into some declarative thing\nfrom the current ad-hoc code we have for each one.\n\nThat would be no change in behavior, but would make it easier to\nmigrate more things in the future.\n\nAnyway, words are cheap. Just replied because to the extent that hIpPy\nwants to work on this I thought I'd sprinkle some historical caveats\nfrom memory. Other than that no point in keeping talking about this\nwithout patches.\n"},{"id":"311953","messageId":"xmqq4lzsqwjy.fsf@gitster.mtv.corp.google.com","threadId":"45160","inReplyTo":"20170217221317.e5kby2jwutdznnlk@sigill.intra.peff.net","subject":"Re: git alias for options","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-02-17T22:31:13Z","receivedAt":"2017-02-17T22:31:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Fri, Feb 17, 2017 at 11:10:08PM +0100, Ævar Arnfjörð Bjarmason wrote:\n>\n>> The most gentle first step would be to try to turn the existing config\n>> options where you can override cli-options into some declarative thing\n>> from the current ad-hoc code we have for each one.\n>> \n>> That would be no change in behavior, but would make it easier to\n>> migrate more things in the future.\n>\n> Yeah, I'd agree with that. It does not change anything for the users,\n> but it makes the implementation less annoying.\n\nYup, as long as that declarative thing (presumably it would hook\ninto parse-options that is already sort of declarative) allows some\ncommand line options not overridable with configuration, I think it\nwould be OK.\n\nI do not think anybody wants to see \"reset --hard\" and turn it into\n\"[reset] hard = yes\" configuration, and we should not even allow for\nthat.\n\n"},{"id":"311954","messageId":"CAM_JFCzoouREM5-6aq9wb0ouT34GKCoJ_pcsww5TYKAdztR9sA@mail.gmail.com","threadId":"45160","inReplyTo":"xmqq4lzsqwjy.fsf@gitster.mtv.corp.google.com","subject":"Re: git alias for options","fromName":"hIpPy","fromEmail":"hippy2981@gmail.com","sentAt":"2017-02-17T22:34:15Z","receivedAt":"2017-02-17T22:35:02Z","isPatch":false,"sender":{"key":"hippy2981@gmail.com","avatar":"https://gravatar.com/avatar/00812eff6e91f90d2c1fe2faccef22d7c475073a1f5b7467152d5174fa61e0cb?d=mp&s=160"},"body":"I think the conversation has drifted away from what I am asking / hoping for.\n\nI apologize but I do not feel in the position of submitting patches\nyet. I'll first need to read some code first before that.\n\nI'm coming from the angle where currently I can alias just the command\n(ex: l for log) not considering the 'command with options'.\n\n[alias]\n l = log\n\nCurrently, the order is as follows:\n\nIf built-in git command then it wins.\nIf custom git command (script as git-l) then it wins.\nIf alias for git command then it wins.\nElse throw as unknown command.\n\nIn short, built-in git command > custom git command > git alias.\n\nSo I think, the same could also be used for options.\n\nSay I want an alias for option --name-status as -s, so I can type:\n$ git log -s\n\nBut there is already a -s option and that wins so the built-in option\nalias wins.\n\nHowever, I think I should be able alias it as --ns.\n$ git log --ns\n\n\nThanks,\nhippy\n"},{"id":"312030","messageId":"20170218063345.3owwc2pwptdv2zu6@sigill.intra.peff.net","threadId":"45160","inReplyTo":"CAM_JFCzoouREM5-6aq9wb0ouT34GKCoJ_pcsww5TYKAdztR9sA@mail.gmail.com","subject":"Re: git alias for options","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-02-18T06:33:45Z","receivedAt":"2017-02-18T06:33:53Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Feb 17, 2017 at 02:34:15PM -0800, hIpPy wrote:\n\n> I think the conversation has drifted away from what I am asking / hoping for.\n\nYeah, the usual answer to \"can we have custom options\" is \"use a custom\nalias\". But I agree they are not quite the same thing.\n\n> Say I want an alias for option --name-status as -s, so I can type:\n> $ git log -s\n> \n> But there is already a -s option and that wins so the built-in option\n> alias wins.\n> \n> However, I think I should be able alias it as --ns.\n> $ git log --ns\n\nTo be honest, I am not that enthused about the idea, but I don't have an\nreal objection beyond \"meh, that looks like an unnecessary\ncomplication\".\n\nIf anybody wants to pursue it, the simplest way would probably be to\nteach parse-options to take a callback for an unknown option, which\ncould then do a config lookup to transmute the argument into another\noption-name.\n\nThough many of the options (notably the revision-walker and diff ones)\nare not handled by parse-options. So that might present a challenge.\n\n-Peff\n"}]}