I'm not totally familiar with the issues here, but from an earlier perusal of the email threads on this, it seems like ASF's concern involves things like git's ability to edit the repository history.
Git's ability to edit the history is a very useful tool. I don't think Subversion or any other VCS prevents you from editing the history either. Maybe they just don't provide tools for that so you'd have to hack the internal data structures of the VCS or something, but you actually want a tool to modify the history. Think about the situation where somebody accidentally pushed a secret private key or a database password to a public repository, you want it out of there! (there's a ton of examples of this in GitHub. git filter-branch is what you should do).
In order to provide "safe" history for Git, the commits must be cryptographically signed by their authors. This is vastly superior compared to trying to use some server side authentication kludge, which can be broken into. And the data structures of the VCS database can be modified, with a hex editor if all else fails. Cryptographic signing provides a guarantee against hex editor hacking too.
If I read one more "Git sucks because you can edit ancient history" comment from someone who doesn't understand the concept of crypto signing, I will cry.
http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
People will notice, and most importantly, everyone will still have the old commit chain locally.
This means that even the server cannot arbitrarily edit history. With SVN, afaik this is possible by manipulating the database.
Git is neat, and I like it, but I'm not planning on studying its internals any time soon.
http://stackoverflow.com/questions/2085871/strategy-for-prev...
I don't know who you expect to convince by baying at the moon.
The ASF people are right in at least one sense: if you don't want to run projects in the ASF style, you are free to take your work elsewhere.
The purpose of my post was not to discuss the merit of the git vs subversion argument, but instead to discuss the merits of jaarons criticism of mikeals article.
One method that established groups resist change is to continue to bring back discussion to issues that have been decided. It helps slow discussion on change by making it appear that a previous issue was not, in fact, resolved. In their mind, of course, its not been resolved: the lawyers were wrong, or perhaps the lawyers didn't understand. Established groups don't just get over it and move on. Why would they?
ASF has decided to allow Git. I believe that those projects which use git will enjoy more success than if they use subversion. Mikeal makes some interesting observations about this. Jaaron spouts the traditional establishment bullshit:
1. The other side are children. We are grown ups.
2. Legal implications.
3. Nobody is forcing you to participate.
4. Condescension. "It's impressive for what it is" ... (but "what it is" is "just a sandbox")
I'm calling it for what it is.
You're jumping at shadows and putting words into his mouth. What he said was:
> Git is an impressive tool and github is awesome for what it is, but it's not a non-profit foundation and it won't replace one.
Which doesn't imply the same condescenscion as your "quote".
Confusing the Apache Software Foundation for your coding sandbox ...This is part of git's interface. (I appreciate it and don't think it's a bogeyman, but can see how it could be incompatible with some projects).
If you want to edit the contents of the repo I think you need to read > filter > rewrite the whole thing. I could be wrong about this, it's been a while since I thought about it.
With git's model, not only does everybody have the history, but the commit ID themselves are your insurance against tampering. You effectively validate that history every time you sync with another git repo.
The reason is that in Git every commit gets its own unique hash so you can't change a commit without creating a new hash. To have this in SVN you have to buy 3rd party tools.
That is true for any digital archive, including those made by any SCM system. The only thing where git differs from svn in that respect are a) that it computes such hashes for you, and (typically/AFAIK) shows those hashes in its UI, and b) that it is typical for people to store those hashes on other systems. The net effect of that may be large or small, depending on the number of people keeping a copy who will not blindly copy changes from the 'main' repository.
No, it is. You can't "falsify a complete repository". We will all have checked out from that repo and as soon as someone replaces it with a fake none of the hashes will match up.
>the only way to detect that it was changed is by comparing its content or a hash thereof with that of a (supposed) copy that is more trusted.
Which happens in the system automatically. Have you actually worked with Git? Go change history on something you've pushed and other people have pulled.
>number of people keeping a copy who will not blindly copy changes from the 'main' repository.
It's not about "blindly copy changes". If you pull from a repo where someone has tried to rewrite history you'll see duplicate entries all over your log. If you have a graphical tool you'll see right where they started their modification.
Stick in a post-commit hook to force a sync to a backup repo nobody has access to if you want to be really paranoid, but as it is, git is already far more resilient against tampering with the public history than svn ever was.