On Fri, 2013-04-12 at 01:05 -0400, Jeff King wrote: > On Thu, Apr 11, 2013 at 09:46:35PM -0700, Junio C Hamano wrote: > > > >> --user:: > > >> ... current description ... > > >> + > > >> (Like|Unlike) many programs that let you run programs as > > >> specified user, the daemon does not reset environment variables > > >> such as $HOME when it runs git programs like upload-pack and > > >> receive-pack. Set and export HOME to point at the home directory > > >> of the user you specify with this option before you start the > > >> daemon, and make sure the Git configuration files in that > > >> directory is readable by that user. > > > > > > So choosing "Like" here, I think this makes sense. > > > > I would prefer the simplicity ;-) > > > > "Set and export HOME to point at the home directory of the user you > > specify with this option" screams that it wants to be rephrased at > > me, though. It somehow sounds as if this option is a way to set and > > export the environment variable unless re-read carefully X-<. > > Perhaps: > > Like many programs that switch user id, the daemon does not reset > environment variables such a `$HOME` when it runs git programs like > `upload-pack` and `receive-pack`. When using this option, you may also > want to set and export `HOME` to point at the home directory of > `<user>` before starting the daemon, and make sure the Git > configuration file in that directory are readable by `<user>`. > > I tried to address your concern above (which I agree with), smooth over > a few clunky wordings, and use "<user>", which is defined in the heading > of the option: > > --user=<user>, --group=<group> I just updated my local rpm to set HOME, so the surprise of no workee after upgrade here is forever gone. Looks like suses (at least) packagers will need to do the same, else canned setup ain't gonna work. -Mike -- 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