7 ms·

Is git that broken? To focus on replacing VCS, you should have a big reason for that I think. I'm just curious.

krupan 11y ago
git is an example of an amazing and powerful new VCS paradigm (distributed), but I sure hope we are not done making better and better tools, like, ever.
- andersonmvd 11y ago
  I also hope we are not done making better and better tools, but to make something better, you need find some gap in current technology and fix it. That's what I am asking: which are the gaps fixed by this VCS? Or in simple terms, why should I switch?
  - mitchtbaum 11y ago
    I personally like very much how Golang and Rust have started to make low-level (mostly old and very important) applications more maintainable for a wider range of contributors (and readable for me); I see (coreutils)[0] as a great example. Also, I would throw Lua into that mix too, at least on some level. As it applies to this particular case, for instance, a repo object management function for lua-git, git implemented in Lua, (`Tree:checkout(path)`)[1] seems like something I could understand. I failed to find git's checkout function, even with a good bit of energy put into it. 0:https://github.com/uutils/coreutils https://github.com/uutils/coreutils 1:https://github.com/mkottman/lua-git/blob/d64218a227fe26b1fc971a8802f74a1921e0187e/lua/git/objects.lua#L84 https://github.com/mkottman/lua-git/blob/d64218a227fe26b1fc9...
  - WorldMaker 11y ago
    Git is a representation of history as a directed acyclic graph (DAG) of commits full of trees that are the state of the repository at the time of the commit. That DAG is strictly ordered (commits point to their parents and this is part of their identity so changing a commit parent makes a new incompatible commit). Darcs (which predates git, by the way) represents a repository as a loosely ordered set of patches (just the changes, not the full state at any given time). Darcs works to know how to rearrange patches in time to create new states. The difference/benefit to this approach is best illustrated with cherry-picking: in Darcs it is very easy to state that I want the patches my fellow developer created for modules X and Y, but I don't think he's done with module Z yet so I'm going to skip those. The patches can be interleaved and recorded in any order and Darcs will do all the hard work of figuring out how to grab just the ones I want, and do so without changing the physical identity of those patches (they are still the same patches my coworker developed). When this works, and it works 98% of the time without an issue, it is a wonderful magic. (Contrast this to git cherry-pick which builds new commits and is likely to have future merge issues with the commits it was built from, even those commits are somewhat "the same".) Pijul is an attempt at getting some of the same magic of a patch-oriented approach (and smarter patch merging) in a post-git world. Also, it's definitely early to talk about switching to Pijul.
- Argorak 11y ago
  How is distributed VCS new? There's quite some prior art even before git. (one of them being Darcs)
gecko 11y ago
Git is the most pervasive implementation of distributed snapshot version control. That model existed for a long time; Git was just the first version that was free (Monotone and tla beat it), fast (Monotone used to be comparable), and had a major reason to adopt it (GitHub finally allowed developers to sanely have a code portfolio) that it became popular. Pijul stands to do the same thing for the patch-based model. Darcs has existed for a long time at this point, but it's not popular, because it's slow. Darcs had the free part from the beginning, but was slow; Pijul is aiming to finally be free and fast enough to allow adoption. If those things both happen, I'd expect a GitHub workalike to show up as well. Being the first with an idea doesn't count for much if you can't execute on it in a way that others like. Darcs clearly has failed at that; Pijul is aiming to do better. We'll have to wait and see if it does.
WorldMaker 11y ago
The word "git" is a Britishism for "idiot"[0], which was actually an intentional choice for the VCS. Git, by design, is not meant to be the smartest VCS on the block, it's just meant to be the one that gets stuff done. Darcs is the "smart" to git's "dumb" and Pijul is exploring if you can have "smart" without sacrificing "fast". There's still plenty of room to explore possible new VCS possibilities, just as we continue to explore things like programming language possibilities. Also, it doesn't necessarily have to replace your existing VCS. Maybe a project like Pijul helps to develop the theory into practice that becomes an amazing new (backward compatible) backend for some future Git N+1 version, for instance. [0] https://en.wikipedia.org/wiki/Git_(slang) https://en.wikipedia.org/wiki/Git_(slang)
- ghusbands 11y ago
  I live in Britain and "git" is not synonymous with "idiot". An idiot is someone who lacks intelligence, or behaves as such. A git is anyone whose behaviour is quite bothersome, perhaps with intent.
  - radiowave 11y ago
    Agreed. A git is typically someone wilfully inconsiderate or rude. Linus gave his VCS that name because, as he put it, "I'm a git".
rbehrends 11y ago
Git isn't broken, but it's sort of the lowest common denominator in the DVCS space. It's a solid workhorse VCS, but it doesn't offer much beyond the essentials. Examples of things Git doesn't do or do well: * Shared mutable history (this is where Pijul/Darcs come into play). * Scaling to large repository sizes [1], especially for monorepos. * More intelligent merging (based on text history and/or semantics). Extracting the full text history of a file can be very expensive in Git (for example, see the performance problems of git blame). * Long-lived branches (due to lack of meta information in Git's storage model, this is often a problem; for example, compare the conceptual complexity of bzr join vs. git subtree). * Annotated history; Git does not have branches in the traditional sense, and this means that history is largely a soup of anonymous objects. Compare this with Fossil's model of propagating tags [2]. [1] See these two talks from Git Merge 2015 for example: http://git-merge.com/videos/git-at-google-dave-borowitz.html http://git-merge.com/videos/git-at-google-dave-borowitz.html and http://git-merge.com/videos/scaling-git-at-twitter-wilhelm-bierbaum.html http://git-merge.com/videos/scaling-git-at-twitter-wilhelm-b... [2] http://fossil-scm.org/xfer/doc/trunk/www/branching.wiki http://fossil-scm.org/xfer/doc/trunk/www/branching.wiki

git is an example of an amazing and powerful new VCS paradigm (distributed), but I sure hope we are not done making better and better tools, like, ever.

andersonmvd 11y ago
I also hope we are not done making better and better tools, but to make something better, you need find some gap in current technology and fix it. That's what I am asking: which are the gaps fixed by this VCS? Or in simple terms, why should I switch?
- mitchtbaum 11y ago
  I personally like very much how Golang and Rust have started to make low-level (mostly old and very important) applications more maintainable for a wider range of contributors (and readable for me); I see (coreutils)[0] as a great example. Also, I would throw Lua into that mix too, at least on some level. As it applies to this particular case, for instance, a repo object management function for lua-git, git implemented in Lua, (`Tree:checkout(path)`)[1] seems like something I could understand. I failed to find git's checkout function, even with a good bit of energy put into it. 0:https://github.com/uutils/coreutils https://github.com/uutils/coreutils 1:https://github.com/mkottman/lua-git/blob/d64218a227fe26b1fc971a8802f74a1921e0187e/lua/git/objects.lua#L84 https://github.com/mkottman/lua-git/blob/d64218a227fe26b1fc9...
- WorldMaker 11y ago
  Git is a representation of history as a directed acyclic graph (DAG) of commits full of trees that are the state of the repository at the time of the commit. That DAG is strictly ordered (commits point to their parents and this is part of their identity so changing a commit parent makes a new incompatible commit). Darcs (which predates git, by the way) represents a repository as a loosely ordered set of patches (just the changes, not the full state at any given time). Darcs works to know how to rearrange patches in time to create new states. The difference/benefit to this approach is best illustrated with cherry-picking: in Darcs it is very easy to state that I want the patches my fellow developer created for modules X and Y, but I don't think he's done with module Z yet so I'm going to skip those. The patches can be interleaved and recorded in any order and Darcs will do all the hard work of figuring out how to grab just the ones I want, and do so without changing the physical identity of those patches (they are still the same patches my coworker developed). When this works, and it works 98% of the time without an issue, it is a wonderful magic. (Contrast this to git cherry-pick which builds new commits and is likely to have future merge issues with the commits it was built from, even those commits are somewhat "the same".) Pijul is an attempt at getting some of the same magic of a patch-oriented approach (and smarter patch merging) in a post-git world. Also, it's definitely early to talk about switching to Pijul.
Argorak 11y ago
How is distributed VCS new? There's quite some prior art even before git. (one of them being Darcs)

gecko 11y ago

Git is the most pervasive implementation of distributed snapshot version control. That model existed for a long time; Git was just the first version that was free (Monotone and tla beat it), fast (Monotone used to be comparable), and had a major reason to adopt it (GitHub finally allowed developers to sanely have a code portfolio) that it became popular. Pijul stands to do the same thing for the patch-based model. Darcs has existed for a long time at this point, but it's not popular, because it's slow. Darcs had the free part from the beginning, but was slow; Pijul is aiming to finally be free and fast enough to allow adoption. If those things both happen, I'd expect a GitHub workalike to show up as well. Being the first with an idea doesn't count for much if you can't execute on it in a way that others like. Darcs clearly has failed at that; Pijul is aiming to do better. We'll have to wait and see if it does.

WorldMaker 11y ago

The word "git" is a Britishism for "idiot"[0], which was actually an intentional choice for the VCS. Git, by design, is not meant to be the smartest VCS on the block, it's just meant to be the one that gets stuff done. Darcs is the "smart" to git's "dumb" and Pijul is exploring if you can have "smart" without sacrificing "fast". There's still plenty of room to explore possible new VCS possibilities, just as we continue to explore things like programming language possibilities. Also, it doesn't necessarily have to replace your existing VCS. Maybe a project like Pijul helps to develop the theory into practice that becomes an amazing new (backward compatible) backend for some future Git N+1 version, for instance. [0] https://en.wikipedia.org/wiki/Git_(slang) https://en.wikipedia.org/wiki/Git_(slang)

ghusbands 11y ago
I live in Britain and "git" is not synonymous with "idiot". An idiot is someone who lacks intelligence, or behaves as such. A git is anyone whose behaviour is quite bothersome, perhaps with intent.
- radiowave 11y ago
  Agreed. A git is typically someone wilfully inconsiderate or rude. Linus gave his VCS that name because, as he put it, "I'm a git".

rbehrends 11y ago

Git isn't broken, but it's sort of the lowest common denominator in the DVCS space. It's a solid workhorse VCS, but it doesn't offer much beyond the essentials. Examples of things Git doesn't do or do well: * Shared mutable history (this is where Pijul/Darcs come into play). * Scaling to large repository sizes [1], especially for monorepos. * More intelligent merging (based on text history and/or semantics). Extracting the full text history of a file can be very expensive in Git (for example, see the performance problems of git blame). * Long-lived branches (due to lack of meta information in Git's storage model, this is often a problem; for example, compare the conceptual complexity of bzr join vs. git subtree). * Annotated history; Git does not have branches in the traditional sense, and this means that history is largely a soup of anonymous objects. Compare this with Fossil's model of propagating tags [2]. [1] See these two talks from Git Merge 2015 for example: http://git-merge.com/videos/git-at-google-dave-borowitz.html http://git-merge.com/videos/git-at-google-dave-borowitz.html and http://git-merge.com/videos/scaling-git-at-twitter-wilhelm-bierbaum.html http://git-merge.com/videos/scaling-git-at-twitter-wilhelm-b... [2] http://fossil-scm.org/xfer/doc/trunk/www/branching.wiki http://fossil-scm.org/xfer/doc/trunk/www/branching.wiki