On Wed, Sep 26, 2018 at 08:16:36AM -0700, Junio C Hamano wrote: > Rasmus Villemoes <rv@xxxxxxxxxxxxxxxxxx> writes: > > > I often use 'git <cmd> --help' as a quick way to get the documentation > > for a command. However, I've also trained my muscle memory to use my > > aliases (cp=cherry-pick, co=checkout etc.), which means that I often end > > up doing > > > > git cp --help > > > > to which git correctly informs me that cp is an alias for > > cherry-pick. However, I already knew that, and what I really wanted was > > the man page for the cherry-pick command. > > > > This introduces a help.followAlias config option that transparently > > redirects to (the first word of) the alias text (provided of course it > > is not a shell command), similar to the option for autocorrect of > > misspelled commands. > > While I do agree with you that it would sometimes be very handy if > "git cp --help" behaved identically to "git cherry-pick --help" just > like "git cp -h" behaves identically to "git cherry-pick -h" when > you have "[alias] cp = cherry-pick", I do not think help.followAlias > configuration is a good idea. I may know, perhaps because I use it > all the time, by heart that "cp" is aliased to "cherry-pick" and > want "git cp --help" to directly give me the manpage, but I may not > remember if "co" was commit or checkout and want to be concisely > told that it is aliased to checkout without seeing the full manpage. > Which means you'd want some way to command line override anyway, and > having to say "git -c help.followAlias=false cp --help" is not a > great solution. I think I responded partially to this hunk in another thread, but I think I can add some additional information here where it is more relevant. One approach to take when digesting this is that 'git co --help' shows you the manual page for 'git-checkout(1)' (or whatever you have it aliased to), so that answers the question for the caller who has a terminal open. In the case where you are scripting (and want to know what 'git co' means for programmatic usage), I think that there are two options. One, which you note above, is the 'git -c help.followAlias=false ...' approach, which I don't think is so bad for callers, given the tradeoff. Another way to go is 'git config alias.co', which should provide the same answer. I think that either would be fine. Perhaps we could assume that 'help.followAlias' is false when it is unset, _and_ isatty(2) says that we aren't a TTY. Otherwise, since I feel that this is a good feature that should be the new default, we can assume it's set to true. Thanks, Taylor
