Re: How to force git to use authentication as author

From: Erik Faye-Lund <kusmabite@gmail.com>
Date: Jul 14, 2011, 11:53 UTC
Message-ID: <CABPQNSY3qyQXO4hyM6xhHq2VYhK5369ihuqJ5PDAonN7+UpcGA@mail.gmail.com>
In-Reply-To: <20110714164547.0b359e60@shiva.selfip.org>

On Thu, Jul 14, 2011 at 1:15 PM, J. Bakshi <joydeep@infoservices.in> wrote:

Show 9 quoted lines

> On Thu, 14 Jul 2011 13:00:02 +0200 Carlos Martín Nieto <cmn@elego.de> wrote:
>> You are misunderstanding either how git works or the nomenclature. The
>> commits all happen locally and need no authentication whatsoever (and
>> usually you're expected to use a real name and email address). When you
>> need to authenticate is when yuou push your changes somewhere (a central
>> repo, for example). This is where the ~/.netrc file comes into play, as
>> I mentioned in the reply to your other mail.
>>
> Exactly, when we need to push we are asked about authentication.

In Git (as you probably know), authentication is not the same as authorship. Because of the distributed nature of Git, a certain change can reach the repo without going through a central repo (e.g by mailing, pushing to a third-party repo etc).

So to be friendly to different work-flows while retaining authorship, authorship (both of the change itself and of the commit object) needed to be decoupled from authentication.

> I like to configure the central git server in a way so that the user-name as in authentication, be set as author name by the git server itself.

There's no way you can setup this from the server-side. Commits are created without communication with the server, again due to the distributed nature of Git.

The only thing you can do at the server-side (and it quickly gets ugly), is to try to validate the pushed commits through a hook. You could probably verify that the authorship is the same as the authentication, but this breaks distributed work-flows. A slightly better approach would be to verify the commiter (as opposed to the patch-author), as this allows for e-mailed patches to retain the original authorship. But it still breaks work-flows that use bundles or pushing between different repos (and probably more), so it's not exactly elegant.

So let's step back a little bit. Why do you want the author to be identical to the authenticated user in the first place? Is it to be able to *prove* (i.e not trust the users that push) who wrote what code? If so, let's me first tell you that giving someone push-access while not trusting them is a bit crazy. But if you're happy with being a bit crazy, you'd might want to somehow cryptographically sign the commits instead. I'd go for PGP-signing the patch-id, and putting that in a git-note.

> actually it is how I configured svn server over http. So comparing to that I am trying to achieve the same. Say your user-name is there at htpasswd file as Carlos, so when you authenticate by Carlos to push , the author-name will automatically become as Carlos. No way to customize that with specific username. That's the idea.

Being the same as in SVN is not a good thing in itself. I've personally had lots of pain when moving SVN servers, because users are a server-local thing (so the repository needs to be rewritten or whatnot). And I'm not even an SVN "power-user". The beauty about having the name + e-mail pair in Git is that the commits do not change no matter what. The history stays the same, you just change the authentication.