On Fri, Sep 28, 2018 at 10:18:05AM +0200, Rasmus Villemoes wrote: > > it, and then it is up to the alias to handle "-h" sensibly. > > I'd be nervous about doing this, though, especially if we introduce this > without a new opt-in config option (which seems to be the direction the > discussion is taking). There are lots of commands that don't respond > with a help message to -h, or that only recognize -h as the first word, > or... There are really too many ways this could cause headaches. > > But, now that I test it, it seems that we already let the alias handle > -h (and any other following words, with --help as the first word > special-cased). So what you're suggesting is (correct me if I'm wrong) > to _also_ intercept -h as the first word, and then print the alias info, > in addition to spawning the alias with the entire argv as usual. The > alias info would probably need to go to stderr in this case. Right, I'm proposing only to add the extra message and then continue as usual. It is a little funny, I guess, if you have a script which doesn't respond to "-h", because you'd get our "foo is aliased to git-bar" message to stderr, followed by who-knows-what. But as long as it's to stderr (and not stdout), I think it's not likely to _break_ anything. > > - "git cp --help" opens the manpage for cherry-pick. We don't bother > > with the alias definition, as it's available through other means > > (and thus we skip the obliteration/timing thing totally). > > It sounds like you suggest doing this unconditionally, and without any > opt-in via config option or a short wait? That would certainly work for > me. It is, in fact, how I expect 'git cp --help' to work, until I get > reminded that it does not... Also, as Junio noted, is consistent with > --help generally providing more information than -h - except that one > loses the 'is an alias for' part for --help. Yes, I'd suggest doing it always. No config, no wait. -Peff
