
Git and github  are not change management tools (rewriting history in git) - mainguy
http://mikemainguy.blogspot.com/2011/08/git-and-github-not-change-mangement.html
======
ezyang
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.)

~~~
mainguy
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.

------
mortice
So, in summary:

"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
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.

~~~
exDM69
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)

~~~
tytso
I've been regularly sending patch series to Gerrit, and it works fine. If
you're not seeing the previous review comments that's because either (a)
you're not adding the Change-ID: lines, or (b) you haven't tried diff'ing
against the previous version of the patch (in which case the review comments
will be clearly visible). Also, the review comments show up in e-mail, of
course.

It's true that Android uses a lot of cherry-picking and rebasing, but that's
because they have to support a large number of releases. That's a development
process choice that the Android folks have made --- but it's not fundamental
to Gerrit.

At least the modern versions of Gerrit have a lot of configuration options,
some of which can be set on a per-user basis (via ACL settings). It's
certainly not perfect, but it is actively being developed, and it is getting
better...

~~~
exDM69
The problem is that when I upload a new patch set for a change that already
exists, all the review comments I had on the previous patch set are "lost".
Also finding the differences between two patches in a change is difficult.

What I'd really want to do in this situation is to have a feature branch where
I push another commit for review. The difference is clearly visible and I can
get new review comments without losing the old ones. This works very well with
Git and GitHub.

~~~
dlsspy
That's exactly how we use gerrit. The most recent change in our gerrit install
is on its sixth revision:

    
    
       http://review.couchbase.org/8560
    

I pulled this one arbitrarily, it just happened to be the top. It's got a
dependency and they change together. It works flawlessly and almost entirely
transparently as long as you have a Change-Id (for which there's a simple hook
to generate).

------
dasil003
A good article for the git initiate, but I could do without the sensational
headline.

------
rlpb
If you don't like this behaviour, you can set a git repository to reject non-
fast-forward pushes to it. Run:

    
    
        git config receive.denyNonFastForwards true
    

This will permit branches to only go in a forward direction.

------
pwg
With apologies to Doug Gwyn -

GIT was not designed to stop you from doing stupid things, because that would
also stop you from doing clever things.

~~~
wtn
Call it Git or git but please not GIT :(

------
BiosElement
Pointless article about user error.

------
escoz
Great read, thanks!

