Re: How to force git to use authentication as author

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> wrote:
> 
> > On Thu, Jul 14, 2011 at 1:38 PM, Carlos Martín Nieto <cmn@xxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxxx> wrote:
> > >> > >
> > >> > > > On Thu, Jul 14, 2011 at 12:36, J. Bakshi <joydeep@xxxxxxxxxxxxxxx>
> > >> > > 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@xxxxxxxxxxx
> > >
> > > 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: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]