git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH] Use SUDO_UID to guess committer identity
Date: Sat, 07 Jun 2008 17:57:28 -0700	[thread overview]
Message-ID: <7vprqsn3pj.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20080608002343.GG12896@spearce.org> (Shawn O. Pearce's message of "Sat, 7 Jun 2008 20:23:43 -0400")

"Shawn O. Pearce" <spearce@spearce.org> writes:

> Junio C Hamano <gitster@pobox.com> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> 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.

      reply	other threads:[~2008-06-08  0:58 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-07  7:11 [RFC PATCH] Use SUDO_UID to guess committer identity Shawn O. Pearce
2008-06-07 21:05 ` Junio C Hamano
2008-06-08  0:23   ` Shawn O. Pearce
2008-06-08  0:57     ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vprqsn3pj.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).