Junio C Hamano wrote: > Jonathan Nieder <jrnieder@xxxxxxxxx> writes: >> The usual >> interface to git's documentation through a man browser is not >> >> man /usr/share/man/man1/git-add.1.gz >> >> but >> >> man git-add; # or "man git add" if your man viewer supports it > > I think you are forgetting the case where the git-man-path the user uses > to install git may be outside /usr/share/man (e.g. $HOME/share/man). In > such an installation, by setting $PATH to include your installed git > binary (e.g. $HOME/bin), you should be able to say "git help -m git" to > tell help.c to internally prepend $HOME/share/man to the $MANPATH before > it kicks "man". I was not forgetting it, but you are right that we have an opportunity to be more helpful in that case. (My own MANPATH already includes ~/share/man, but I can see that it is easy to forget to add.) I am still not very happy about it. The man browser is in a much better position to help: the default MANPATH (at least under Debian; see manpath(5)[1]) is generated by mapping $PATH entries on the fly, and it seems like only an oversight that it deals with directories under /usr but not /home. And it does not thrill me that we would be training people that git help git will cover for the installer's mistakes, while the more conventional man git mechanism (which is also used for other programs installed to $HOME) will not. > Isn't that what this patch is solving? I find the "use the right version of help when multiple copies of git" use case compelling enough already. Please don't mind my complaints too much. Thanks for clarifying. Jonathan [1] http://man.he.net/man5/manpath -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html