git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Carlos Martín Nieto" <cmn@elego.de>
To: "J. Bakshi" <joydeep@infoservices.in>
Cc: kusmabite@gmail.com, "Ævar Arnfjörð" <avarab@gmail.com>,
	git@vger.kernel.org
Subject: Re: How to force git to use authentication as author
Date: Thu, 14 Jul 2011 14:26:05 +0200	[thread overview]
Message-ID: <1310646365.6041.46.camel@centaur.lab.cmartin.tk> (raw)
In-Reply-To: <20110714174916.07dd314d@shiva.selfip.org>

[-- Attachment #1: Type: text/plain, Size: 5796 bytes --]

On Thu, 2011-07-14 at 17:49 +0530, J. Bakshi wrote:
> On Thu, 14 Jul 2011 14:00:06 +0200
> Erik Faye-Lund <kusmabite@gmail.com> wrote:
> 
> > On Thu, Jul 14, 2011 at 1:38 PM, Carlos Martín Nieto <cmn@elego.de> wrote:
> > > On Thu, 2011-07-14 at 16:45 +0530, J. Bakshi wrote:
> > >> On Thu, 14 Jul 2011 13:00:02 +0200
> > >> Carlos Martín Nieto <cmn@elego.de> wrote:
> > >>
> > >> > On Thu, 2011-07-14 at 16:18 +0530, J. Bakshi wrote:
> > >> > > On Thu, 14 Jul 2011 12:38:59 +0200
> > >> > > Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> > >> > >
> > >> > > > On Thu, Jul 14, 2011 at 12:36, J. Bakshi <joydeep@infoservices.in>
> > >> > > wrote:
> > >> > > >
> > >> > > > > How can I force git to use the username as define
> > >> > > at /home/git/PASSWD as the author name for git commit ?
> > >> > > >
> > >> > > > Edit the global bashrc to have:
> > >> > > >
> > >> > > >     export GIT_AUTHOR_NAME=$(cat ~/PASSWD)
> > >> > > >
> > >> > > > ?
> > >> > >
> > >> > > Thanks.
> > >> > >
> > >> > > [1] will it work with file generated by htpasswd ? as that file is
> > >> > > actually created by same (/home/git/PASSWD)
> > >> >
> > >> > Not directly, if it only has one line, then $(cat ~/PASSWD | cut -d ':'
> > >> > -f 1) should work, but I haven't tested it.
> > >> >
> > >> > >
> > >> > > [2] And the commit is over http, So is it effective to set the value
> > >> > > by .bashrc ?
> > >> >
> > >> > 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. 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. 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.
> > >
> > > That's not how it works. It may even be possible to rewrite the commits
> > > in the post-receive hook in a way that most stuff doesn't break
> > > horribly, this would be rewriting history behind the users' backs, and
> > > that only brings problems.
> > 
> > This will (as you point out) only lead to problems, because rewriting
> > the history at commit-time will have the effect that a push leaves you
> > in the situation where you end up with a different history on the
> > workstation and the server. All branches off the pushed branch will
> > become a hell, and a clusterfck of darkness and terror will take over.
> > 
> > > The way to set the author name and mail in a standard way, be it
> > > user-wide or per-repo. You can write up some simple instructions on how
> > > to do it.
> > >
> > >    git config user.name "Max Smith"
> > >    git config user.mail max.smith@example.com
> > >
> > > and if the config should be valid for every repo, use --global flag.
> > > There is more information in the manual page.
> > >
> > > You could then add a check in the post-receive hook to reject pushes
> > > with invalid author names, if you feel it's worth it.
> > >
> > 
> > Denying a push is much more elegant than rewriting, but (as I pointed
> > out in my other mail) also has a lot of problems with distributed
> > work-flows. And let's face it when changing from SVN to Git, the
> > distributed nature is about the last feature that you'd want to give
> > up ;)
> > 
> > > Taking a step back, why is this even an issue, though? If you don't
> > > trust your developers to set their name and email correctly, why do you
> > > trust them to write code? If it's company policy for people to be
> > > referred to by their usernames rather than their given names, why not
> > > tell them to set it to that[0]? It seems like you are trying to solve a
> > > social issue with a technological measure that works at a different
> > > level.
> > 
> > Very well said, I completely agree!
> 
> As I mentioned already in my previous mail, it is not an issue but we
> presently use it with svn in a positive way.
> Say 5 designer are working with same template, but in different
> section. So it is very easy to understand who is working on what
> and also these 5 designers can see/review the codes among them and how
> previous code effect their work. So this features are exploited here
> with that positive
> direction. 
> 

I don't see how using people's real name is any less clear about who
they are. Alternatively, you can use their email addresses to tell them
apart.

With git, you can fetch the changes from either a central repository or
a particular developer's/designer's repo and see what they are changing
without affecting your local copy. Say you fetch from developer B's repo
and you want to see what the differences are, you just do

    git diff B/some-branch

or if you want to see if the changes would merge cleanly, you create a
(local) branch and try to merge there. Or you can do it on your dev
branch and roll-back if it doesn't work.

How does your current workflow depend on usernames? From what you
describe, the above would work just as well.

Cheers,
   cmn

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2011-07-14 12:26 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-14 10:36 How to force git to use authentication as author J. Bakshi
2011-07-14 10:38 ` Ævar Arnfjörð Bjarmason
2011-07-14 10:48   ` J. Bakshi
2011-07-14 11:00     ` Carlos Martín Nieto
2011-07-14 11:15       ` J. Bakshi
2011-07-14 11:38         ` Carlos Martín Nieto
2011-07-14 12:00           ` Erik Faye-Lund
2011-07-14 12:19             ` J. Bakshi
2011-07-14 12:26               ` Carlos Martín Nieto [this message]
2011-07-14 12:01           ` J. Bakshi
2011-07-14 12:16             ` Ferry Huberts
2011-07-14 12:44           ` Jakub Narebski
2011-07-14 11:38         ` J. Bakshi
2011-07-14 11:53         ` Erik Faye-Lund
2011-07-14 19:45           ` Jonathan Nieder

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=1310646365.6041.46.camel@centaur.lab.cmartin.tk \
    --to=cmn@elego.de \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=joydeep@infoservices.in \
    --cc=kusmabite@gmail.com \
    /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).