1

My situation is the following: there are 2 people who have access to a private repo and work together on the code. But one guy has wrote a code on other guy's computer and now wants to commit for his name not for the name of that other guy.

I have seen here how to commit for another author for the repository. I have done that but it is strange that it didn't require password of the author for whose name I was committing. It is not normal. So people can commit for myself a code that I have not written and I am not responsible for?

Community
  • 1
  • 1
Narek
  • 38,779
  • 79
  • 233
  • 389
  • git identities don't have passwords - they're just configured in your `.gitconfig` file. – sevenseacat Mar 17 '15 at 06:45
  • When you clone the repo you need a password, right? Even I remember on Windows for each commit Tortoise Git was requiring a password. Why I should be able to commit for other person without a password then. – Narek Mar 17 '15 at 06:48
  • Because that's how Git works. Your Git hosting server (to which you eventually push your commits) might not allow you to impersonate other users, but Git itself doesn't care. – Magnus Bäck Mar 17 '15 at 07:00
  • So anyone can commit for me if they have the clone of the repo? :) – Narek Mar 17 '15 at 07:04
  • Yes. But as I said, they might not be able to publish the commits. – Magnus Bäck Mar 17 '15 at 07:16
  • @MagnusBäck what you mean they might not be able to publish the commits? What does publish mean in your context? – Narek Mar 17 '15 at 08:21
  • By publish I mean push to another repository. You can do whatever you want in your local repository, but if you want to push your commits to someone else's repository you have to abide by their rules, which might include restrictions on the authors and/or committers of the commits you're pushing. – Magnus Bäck Mar 17 '15 at 11:13

2 Answers2

1

Yes. With git you can make commit under any personality you want. But you can use a gpg-sign for assurance that this commit is yours in future:

1. Create a key:

~$ gpg --gen-key

2. Add to .gitconfig key that you want to use:

[user]
    ....
    signingkey = E4634C2C

3. Make a signed commit:

~$ git commit -s -m "Signed commit"

But there is some cons:

  1. You need to enter pass before commit.
  2. You need a secret gpg-key on current local host.
Alexander Yancharuk
  • 13,817
  • 5
  • 55
  • 55
1

Git does not handle any authorization. The way it works, you can just change your identity using git config or the --author argument to make commits as whoever you want. These commits will stay local to your computer until you decide to push them.

Remote servers often opt in to have some sort of authentication. This is most commonly done using the SSH protocol. In addition, many add a authorization layer that restricts you from accessing repositories. For example on GitHub, you may only push to repositories that you own or to which you explicitely got write access.

This access control however does only apply to the act of pushing changes. So if you have access to a repository, you can push whatever commits you want, with whatever author you want. It is possible that providers add a check that rejects pushes when they contain commits that are not authored (or committed) by the pushing user. However, this behavior is usually not desired.

The reason for that is that Git is a distributed version control system. So unlike for example Subversion, people don’t have to use the same centralized server which can then ensure that you only publish changes made by yourself (Subversion actually just assumes this and the “commits” are only created on the server). Instead, it is possible—and often desired—that commits go different routes until they land on central repositories (multiple repositories are common too). You could even work directly with another developer and push changes into, or pull changes from their private repository without ever having to interact with some sort of central server. And when you then decide to publish commits to a central server, of course that central server should not reject your changes just because you included commits by that other developer.

So no, there is no guarantee that someone else isn’t using your “identity” to create commits in your name. Git does however support signing commits, to allow you to prove that a commit is of your own. Anyone that is then interested in validating it can then check the signature on the commit and verify that it was really made by yourself. Some repository servers may even require that all commits that are pushed to the server are signed, and then verify the signature on each commit. But that is totally optional and not something Git comes with by default; because by default Git is just a “stupid content tracker”.

poke
  • 369,085
  • 72
  • 557
  • 602