Since there hasn't been any movement on the alternative solutions mentioned here, would it be reasonable to accept this patch in the meantime?
-- Keith Smiley > On Jan 17, 2018, at 01:48, Duy Nguyen <pclo...@gmail.com> wrote: > >> On Wed, Jan 17, 2018 at 1:17 PM, Kevin Daudt <m...@ikke.info> wrote: >>> On Wed, Jan 17, 2018 at 07:44:19AM +0700, Duy Nguyen wrote: >>> PS. This also makes me thing about supporting subcommand aliases, so >>> that people can add back 'git remote rm' if they like (or something >>> like 'git r rm' when they alias 'remote' as well). Which is probably a >>> good thing to do. Long command names are fine when you have completion >>> support, they are a pain to type otherwise. >>> >> >> Couldn't they just create an alias like git rrm then, if they use it so >> often that it becomes an issue? > > They could. The only exception that may not work is if they want to > insert some options between "r" and "rm". Sometimes option positions > matter. Anyway this is just thinking out loud, maybe we don't really > need it until people scream about it with a valid use case > >> Having another layer of aliases does create a lot of complexity. > > Yes. It's partly the reason I wanted this actually ;-) Many commands > have gained subcommands nowadays but there's no shared infrastructure > for managing these subcommands. By adding something that works across > the board at subcommand level I'm forced to "fix" this (or probably > never get to do the sub-aliasing because this "fix" takes forever). > -- > Duy
