"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> wrote: >> "Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: >> >> > When invoking Git commands though sudo against a bare repository >> > with reflogs enabled we should attempt to record the actual user's >> > information in the reflog, not the identity of the user sudo entered. >> > >> > For example when executing: >> > >> > sudo -u gitadm git --git-dir=/srv/git.git branch -f pu master >> > >> > We want record information about the caller of sudo, not gitadm. > ... > The issue is when users run commands though sudo, but forget to set a > value for GIT_COMMITTER_NAME/EMAIL, or to configure ~/.gitconfig in > their personal account. In your scenario, is the above "sudo -u gitadm" the exact command line the end users type, or is it wrapped in the script you give to them? > Eh, I'm myself not entirely happy with the patch. It honors the > real user's $HOME/.gitconfig user.name/email settings and not the > SUDO_UID data. I'd almost prefer favoring SUDO_UID over whatever > we inherit in from the enviroment or from $HOME/.gitconfig when it > comes to committer identity. The thing is, I personally hate pseudo and wish that your solution did not rely on SUDO_UID which is too specific to that hack. Sometimes people need to lie to their SCM when doing things in behalf of somebody else, and I agree we would want to give them a way to do so. And we do, just like RCS and CVS honor LOGNAME. If you have /etc/hosts under RCS control but you do not want all the log entries to say 'root', and you would do: $ cd /etc $ su root# edit /etc/hosts root# LOGNAME=me ci -u -m 'Add host bar' hosts When omebody asks you to help him fixing his bug, you go to his keyboard, show him how it should be done, and you concude the session with: his shell$ LOGNAME=me ci -u -m 'Fix foo' foo.c The point is that the same mechanism works (because it is designed to) in both cases. -- 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
