3 ms·

He compares it to SVN, but makes a classic error. In SVN branches and commits are just as cheap as in git (albeit marginally slower to create usually). It's the

• _ikke_ 14y ago
  Branching in SVN is not cheap. It basically has to copy the entire directory structure into a new subdirectory (branches directory). In git, it just creates one file with a 40 byte hex.
  • rkangel 14y ago
    Errr, no - while that's what you see in the directory tree, that's not how it's done internally. SVN has a data model where multiple paths in the repo tree can point to the same underlying file object, so a branch requires no file copies, just updating what the directory tree looks like. Even that is done in a very efficient way. It might not quite be 40 bytes, but it is negligibly small. This technique is in fact extremely similar to how Git works.
  • andrewaylett 14y ago
    Server-side, that's cheap -- it doesn't actually copy any data. Client-side, it's also cheap: you `svn switch` to the new branch, which is identical to your old branch, so only minimal housekeeping on disk (just like git).
• Peaker 14y ago
  Beyond branches being expensive, even commits in svn are expensive. They publish immediately, which requires proof-reading, more testing, before each commit. This means there's an incentive to wait with commits. Even if you do commit to a branch, where publishing is less of a problem, you still might regret a typo in the commit, which cannot (easily) be retroactively fixed whereas in git you can fix your private/unpublished commits as much as you'd like with virtually no drawbacks.
  • rkangel 14y ago
    Good point - I suppose I hadn't considered it like that. I tend to happily commit to my feature branch on SVN and then make sure that the log message is good when I merge to trunk. Incidentally you can edit previous log messages in SVN, it's just that most servers have it disabled, for traceability.
    • Peaker 14y ago
      In git you can edit the commit content as well retroactively.