On Thu, Jul 14, 2011 at 1:15 PM, J. Bakshi <joydeep@xxxxxxxxxxxxxxx> wrote: > On Thu, 14 Jul 2011 13:00:02 +0200 Carlos Martín Nieto <cmn@xxxxxxxx> 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. -- 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