4 ms·

There's no reason apache can't maintain its own "legally authorative" git repo. Nothing in the authors post suggest that he is confusing the ASF with a "coding

by buff-a 15y ago

There's no reason apache can't maintain its own "legally authorative" git repo. Nothing in the authors post suggest that he is confusing the ASF with a "coding sandbox". Making that claim suggests to me that you are invested in the alternative and not thinking objectively. And I disagree about subversion being "made for Apache in the way Linus made git for Linux". Subversion is an utterly derivative implementation of any server based VCS in existence, where as git is an example of truly creative thought (not just from Linus) about what VCS should be for a large community that requires the accountability that you claim ASF requires.

tptacek 15y ago
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.
- buff-a 15y ago
  Oh, I can think of a million scary sounding consequences of using git and I'm sure that all were raised. This is what established groups do when confronted with change: raise any objection even though a moments thought demonstrates the paucity of its merits.
  - tptacek 15y ago
    That moment of thought was apparently too expensive for you; you didn't respond to the actual concern, but rather raised an argument suggesting that any argument about git must be meritless. 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.
    - buff-a 15y ago
      I need not respond to the actual concern because the ASF has already done so. The ASF has already decided to allow git to be used. I assume that their lawyers OK'd this change. So I did not intend to continue an ongoing discussion: ASF has already concluded that discussion and approved git. Clearly, jaaron does not represent the views of all the "ASF People", and for him to raise issues as legal showstoppers when the lawyers have clearly approved is utterly disingenuous. 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.
      - bct 15y ago
        > 4. Condescension. "It's impressive for what it is" ... (but "what it is" is "just a sandbox") 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".
        reissbaker 15y ago
        The very next line: Confusing the Apache Software Foundation for your coding sandbox ...
        bct 15y ago
        But he does not say "just a sandbox", or otherwise imply that a "coding sandbox" is less valuable than a non-profit organization. They're different things.
- DannoHung 15y ago
  I'm not super familiar with subversion's internals, but couldn't a malicious user edit a subversion repo history?
  - tptacek 15y ago
    Without access to the database itself? How? 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).
    - buff-a 15y ago
      As I understand it, if the repo has receive.denynonfastforwards=true, a user can't push changes that will destroy history. This flag has been available since 2006. (And I didn't mod you down. You ask a legitimate question). A bit more research shows that there a couple more config changes required: http://stackoverflow.com/questions/2085871/strategy-for-preventing-or-catching-git-history-rewrite http://stackoverflow.com/questions/2085871/strategy-for-prev...
  - aidos 15y ago
    I don't think it's easy to do. You can change a commit message, but even that's not easy (you basically need admin access to the repo files). 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.
    - nknight 15y ago
      Which is utterly trivial (I've done it, seriously, it's not the big deal you seem to think it is, aside from the obvious difficulty of particularly large repos), and is not conceptually different from what's necessary for editing git's history, except that nobody can tell you've done it without comparing the "new" repo to the old one -- and under svn's internal model, no one but the server will normally have a complete history. 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.
- nknight 15y ago
  Yeah, that particular bit of FUD is quite popular with the anti-git crowd. It's nonsense. Any attempt to edit the history of a public repository will be noticed instantly by anybody who tries to sync up, no matter what. 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.
  - icefox 15y ago
    Just turn of garbage collection (it isnt instant but i wouldnt bet that it would still be there in six months) and even if you rewrite the history you won't lose the objects. No need for a backup sync
- JoshTriplett 15y ago
  Git normally only allows you to edit unpublished history; the server can prohibit editing of published history. Similarly, svn allows history editing if the server permits it.
  - onedognight 15y ago
    See Fedora's git repository for an example of how to do this.
    - jhawk28 15y ago
      I believe they use gitolite to do this. (https://github.com/sitaramc/gitolite https://github.com/sitaramc/gitolite)
- buff-a 15y ago
  In discussion of an article which makes the claim "The problem here is less about git and more about the chasm between Apache and the new culture of open source." it is ironic that an objection is raised that is trivially answered by using one of the very proponents of this new "open knowledge" culture, Stack Overflow: http://stackoverflow.com/questions/2085871/strategy-for-preventing-or-catching-git-history-rewrite http://stackoverflow.com/questions/2085871/strategy-for-prev...
- wladimir 15y ago
  You of all people should know that GIT history consists of a write-only log which is maintained using cryptographic hashes. If you edit one commit (even the metadata) you have to rewrite history, and all the hashes for commits after it change. 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.
  - tptacek 15y ago
    "Me of all people"? People sure are zealous about their version control systems. For the record, I use git. But I don't really give a shit about it. For most of my career, I used CVS. Git is neat, and I like it, but I'm not planning on studying its internals any time soon.
    - wladimir 15y ago
      Right. But it is useful to know, not so much because of the VCS aspect, but because of the security aspect. Hg/Mercurial BTW works in the same way.
- exDM69 15y ago
  tl;dr: Sign your Git commits cryptographically with PGP if you don't want the history to be editable. 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.
  - buff-a 15y ago
    Discussion on this subject with a reply from Linus: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...
rgardler 15y ago
You are right, there is no reason why the ASF can't own its own "legally authorative" git repo. That is exactly why the ASF is conducting experiments in exactly that. Assuming those experiments are a success and representatives of ASF users are happy (which include business folk and lawyers, not just developers) then the ASF will role Git out to all projects that want it. This whole argument is moot.

by buff-a 15y ago

tptacek 15y ago

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.

buff-a 15y ago
Oh, I can think of a million scary sounding consequences of using git and I'm sure that all were raised. This is what established groups do when confronted with change: raise any objection even though a moments thought demonstrates the paucity of its merits.
- tptacek 15y ago
  That moment of thought was apparently too expensive for you; you didn't respond to the actual concern, but rather raised an argument suggesting that any argument about git must be meritless. 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.
  - buff-a 15y ago
    I need not respond to the actual concern because the ASF has already done so. The ASF has already decided to allow git to be used. I assume that their lawyers OK'd this change. So I did not intend to continue an ongoing discussion: ASF has already concluded that discussion and approved git. Clearly, jaaron does not represent the views of all the "ASF People", and for him to raise issues as legal showstoppers when the lawyers have clearly approved is utterly disingenuous. 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.
    - bct 15y ago
      > 4. Condescension. "It's impressive for what it is" ... (but "what it is" is "just a sandbox") 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".
      - reissbaker 15y ago
        The very next line: Confusing the Apache Software Foundation for your coding sandbox ...
        bct 15y ago
        But he does not say "just a sandbox", or otherwise imply that a "coding sandbox" is less valuable than a non-profit organization. They're different things.
DannoHung 15y ago
I'm not super familiar with subversion's internals, but couldn't a malicious user edit a subversion repo history?
- tptacek 15y ago
  Without access to the database itself? How? 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).
  - buff-a 15y ago
    As I understand it, if the repo has receive.denynonfastforwards=true, a user can't push changes that will destroy history. This flag has been available since 2006. (And I didn't mod you down. You ask a legitimate question). A bit more research shows that there a couple more config changes required: http://stackoverflow.com/questions/2085871/strategy-for-preventing-or-catching-git-history-rewrite http://stackoverflow.com/questions/2085871/strategy-for-prev...
- aidos 15y ago
  I don't think it's easy to do. You can change a commit message, but even that's not easy (you basically need admin access to the repo files). 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.
  - nknight 15y ago
    Which is utterly trivial (I've done it, seriously, it's not the big deal you seem to think it is, aside from the obvious difficulty of particularly large repos), and is not conceptually different from what's necessary for editing git's history, except that nobody can tell you've done it without comparing the "new" repo to the old one -- and under svn's internal model, no one but the server will normally have a complete history. 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.
nknight 15y ago
Yeah, that particular bit of FUD is quite popular with the anti-git crowd. It's nonsense. Any attempt to edit the history of a public repository will be noticed instantly by anybody who tries to sync up, no matter what. 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.
- icefox 15y ago
  Just turn of garbage collection (it isnt instant but i wouldnt bet that it would still be there in six months) and even if you rewrite the history you won't lose the objects. No need for a backup sync
JoshTriplett 15y ago
Git normally only allows you to edit unpublished history; the server can prohibit editing of published history. Similarly, svn allows history editing if the server permits it.
- onedognight 15y ago
  See Fedora's git repository for an example of how to do this.
  - jhawk28 15y ago
    I believe they use gitolite to do this. (https://github.com/sitaramc/gitolite https://github.com/sitaramc/gitolite)
buff-a 15y ago
In discussion of an article which makes the claim "The problem here is less about git and more about the chasm between Apache and the new culture of open source." it is ironic that an objection is raised that is trivially answered by using one of the very proponents of this new "open knowledge" culture, Stack Overflow: http://stackoverflow.com/questions/2085871/strategy-for-preventing-or-catching-git-history-rewrite http://stackoverflow.com/questions/2085871/strategy-for-prev...
wladimir 15y ago
You of all people should know that GIT history consists of a write-only log which is maintained using cryptographic hashes. If you edit one commit (even the metadata) you have to rewrite history, and all the hashes for commits after it change. 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.
- tptacek 15y ago
  "Me of all people"? People sure are zealous about their version control systems. For the record, I use git. But I don't really give a shit about it. For most of my career, I used CVS. Git is neat, and I like it, but I'm not planning on studying its internals any time soon.
  - wladimir 15y ago
    Right. But it is useful to know, not so much because of the VCS aspect, but because of the security aspect. Hg/Mercurial BTW works in the same way.
exDM69 15y ago
tl;dr: Sign your Git commits cryptographically with PGP if you don't want the history to be editable. 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.
- buff-a 15y ago
  Discussion on this subject with a reply from Linus: http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-td2582986.html http://git.661346.n2.nabble.com/GPG-signing-for-git-commit-t...

rgardler 15y ago

You are right, there is no reason why the ASF can't own its own "legally authorative" git repo. That is exactly why the ASF is conducting experiments in exactly that. Assuming those experiments are a success and representatives of ASF users are happy (which include business folk and lawyers, not just developers) then the ASF will role Git out to all projects that want it. This whole argument is moot.