From: Nick <oinksocket@letterboxes.org>
To: git@vger.kernel.org
Subject: avoiding anonymous commits from root/shared accounts
Date: Mon, 10 May 2010 18:05:17 +0100 [thread overview]
Message-ID: <4BE83CCD.2090505@letterboxes.org> (raw)
Hi,
I have a question about what is probably an unusual use-case, where git is being
used from the root account, or an account shared by various committers.
I'm setting up a shared git repository, currently accessed via plain ssh to the
server in question. The code has been inherited, and is migrated from CVS.
The code is a sysadmin tool designed to set up a new server and keep its
configuration synchronised to one of several templates thereafter. Typically, it
is checked out in /root on a freshly installed server, and "make all" is run as
root to configure the services, set up user accounts, etc.
>From then on you pull updates from the repository, run "make all", and the
machine is reconfigured, services restarted, etc. as necessary.
The problem is maintenance of this code. In the past, fixes might be made on
any server, then pushed back into the repository to be replicated everywhere.
There are several users, each of whom might commit changes to this tool. When
it was in CVS, a common account was used to allow commits from anyone and
anywhere - and as a result nothing can be attributed to anyone.
I want to avoid these anonymous commits from now on. The trouble is, I'm not
sure the best way to, as there is no guarantee any accounts but root will exist,
and if they do, some of these are shared accounts various people can log in as.
(This may or may not be advisable, but for now that's the way it works)
I also don't want to make it easy for the maintainers to do the right thing,
they will already be re-adjusting to git. For that reason, just mandating that
everyone sets $GIT_AUTHOR_NAME etc. manually on log-in isn't very satisfactory.
The best idea I've come across seems to be some sort of wrapper for git, which
if no $GIT_USER_* is defined, can use $SUDO_USER and/or `who am i` to identify
the original log-in account, and sets $GIT_AUTHOR_NAME etc. - else if it can't
do this, it refuses to commit. Or perhaps it would be a script which spawns a
shell with the right environment to invoke git commands from, after successfully
determining the identity.
But before I investigate this avenue any further, I wonder is there any prior
art addressing this sort of situation, using git?
Thanks
Nick
next reply other threads:[~2010-05-10 17:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-10 17:05 Nick [this message]
2010-05-10 21:11 ` avoiding anonymous commits from root/shared accounts Alex Vandiver
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=4BE83CCD.2090505@letterboxes.org \
--to=oinksocket@letterboxes.org \
--cc=git@vger.kernel.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).