The author is misguided about (1) the technical details behind Git (all commits are hashed, so if you cryptographically sign a particular commit tag, it will definitely point to that commit and its attendant history), as well as (2) the obvious/non-obviousness of a rewritten history (if upstream rebases, it's really obvious.)
You're absolutely right, that was kinda the point of the article. I've run across quite a few people who think git is "distributed svn" and the gap between these two tools is much bigger than most appreciate.
You can ammend history in any repository, but all other repositories still have the original state. Hence, someone who tries to tamper with git history in such a way can't do it undetectably. It will be blatently obvious to all that the history has been rewritten, and all other copies of the repositories will contain the original history.
If you are going to use git in a centralized way, I suggest you use Gerrit. In addition to providing code review functionality, Gerrit also gives user authentication and you per-user access controls. This allows you to restrict what a user can do when he pushes, so that he can only update a branch (i.e., push new content), and not delete a branch or do a "force push" (which is what you would need to do if you want to replace a branch with entirely new content).
It's also possible to customize Gerrit to only allow a user to push changes that he or she wrote herself, which will give you a much more strict audit trail. And you can set these access control parameters on a per-branch basis, so you could allow the release manager to push new changes onto the vendor branch, but all changes to the production branch must be committed by the person submitting the change, and go through code review.
So the basic take-away from the article is (a) git is a distributed SCM, not a centralized SCM; and if you want to use git in a centralized SCM fashion, don't do it incompetently --- instead you should use Gerrit, which is designed as a wrapper to Git so it can a secure, auditable, centralized repository.
I use Gerrit at work and I do not recommend it to anyone. It's a half-assed tool that essentially turns Git into something that's worse than tarballs, diff+patch and an e-mailing list. The Gerrit UI is horrible, it can handle only one patch changes (worse than pull requests) and every time you upload a new patch, all your previous review comments are hidden with the old version of the patch.
Gerrit (and Android's repo) are based on cherry-picking and rebasing, not branching and merging. They will turn your history into a mess in any non-trivial setting. It also doesn't support Git submodule trees.
What the original article author wants is some kind of security. Git's way of doing that is GPG signatures.
My advice: if you have a choice, do NOT use Gerrit for anything. GitHub is gazillion times better.
(note: we might not be using the latest version of Gerrit, however it's so bad that I don't think a new version will help)
[+] [-] ezyang|14 years ago|reply
[+] [-] mainguy|14 years ago|reply
[+] [-] mortice|14 years ago|reply
"A hammer can be used for the following things:
1. To drive nails into another material
2. To 'hammer out' dents in sufficiently soft materials
3. As a weapon
4. As a doorstop
5. etc.
Because some people only use it to do (1) and (3), it isn't a tool for (2)."
P.S. I know the author acknowledges this in his own comment on the article.
[+] [-] tytso|14 years ago|reply
If you are going to use git in a centralized way, I suggest you use Gerrit. In addition to providing code review functionality, Gerrit also gives user authentication and you per-user access controls. This allows you to restrict what a user can do when he pushes, so that he can only update a branch (i.e., push new content), and not delete a branch or do a "force push" (which is what you would need to do if you want to replace a branch with entirely new content).
It's also possible to customize Gerrit to only allow a user to push changes that he or she wrote herself, which will give you a much more strict audit trail. And you can set these access control parameters on a per-branch basis, so you could allow the release manager to push new changes onto the vendor branch, but all changes to the production branch must be committed by the person submitting the change, and go through code review.
So the basic take-away from the article is (a) git is a distributed SCM, not a centralized SCM; and if you want to use git in a centralized SCM fashion, don't do it incompetently --- instead you should use Gerrit, which is designed as a wrapper to Git so it can a secure, auditable, centralized repository.
[+] [-] exDM69|14 years ago|reply
Gerrit (and Android's repo) are based on cherry-picking and rebasing, not branching and merging. They will turn your history into a mess in any non-trivial setting. It also doesn't support Git submodule trees.
What the original article author wants is some kind of security. Git's way of doing that is GPG signatures.
My advice: if you have a choice, do NOT use Gerrit for anything. GitHub is gazillion times better.
(note: we might not be using the latest version of Gerrit, however it's so bad that I don't think a new version will help)
[+] [-] dasil003|14 years ago|reply
[+] [-] rlpb|14 years ago|reply
[+] [-] pwg|14 years ago|reply
GIT was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.
[+] [-] wtn|14 years ago|reply
[+] [-] BiosElement|14 years ago|reply
[+] [-] escoz|14 years ago|reply