1. 32

    Git is horribly broken

    I hear this sentiment a lot, but I’ve never heard a detailed argument as to why or how it’s broken from people who have invested time into learning it. I use it daily even when working on solo projects. While it had an initial learning curve and caused a few headaches while diving in, now that I grok it pretty well I can’t think of a better way to implement most of its functionality. Are there any git detractors that have used git extensively here who’d like to weigh in with git’s downfalls or better ways to implement a distributed version control system?

    On a side note, if one’s frustration is with git in the command line, magit is phenomenal and is a good enough reason in itself to install emacs.

    1. 17

      Are there any git detractors that have used git extensively here who’d like to weigh in with git’s downfalls or better ways to implement a distributed version control system?

      I use Git every day but I think the model could be better. I think the work in patch theory is useful:

      https://tahoe-lafs.org/~zooko/badmerge/simple.html

      https://pijul.org/documentation/model/#why-care-about-patch-theory

      http://darcs.net/Using/Model

      For example:

      Pijul lets you describe your edits after you’ve made them, instead of beforehand.

      1. 16

        I think if you think people who struggle with git won’t struggle with emacs, you are about to be disappointed. Git has some rough edges with ux, and this is only made worse by the fact that the problem it solves isn’t trivial to understand. That being said I think the author is wrong, people will use git despite its usability shortfalls. requiring “always connected to the internet” is a fundamental misunderstanding of why git is presently popular, and since the author is investing in this direction they are poised to lose a lot of money. I genuinely can’t imagine a non-opensource VCS toppling git, either it’s just silly.

        1. 15

          I hear this sentiment a lot, but I’ve never heard a detailed argument as to why or how it’s broken from people who have invested time into learning it.

          There have been papers about that. They were discussed previously along with the VCS built to adress the shortcomings:

          1. 9

            Not sure how Gitless fits here. Gitless is based on Git, at the core of Gitless, is Git. If Git itself is broken, how Gitless can fix it?

            1. 4

              Gitless is an alternative UI to git and git’s UI is a major common complaint

              1. 2

                Gitless’s authors main complaint is that Git’s interface is conceptually complex, Gitless reduces the API and combines some of the underlying concepts in Git. It seems like a reasonable goal although I haven’t actually used Gitless myself so I can’t really give a first hand account on if it’s successful. In any case, it seems reasonable to build a functional system by some criteria on top of a broken system by that same criteria.

              2. 4

                Thank you! Exactly what I was looking for, checking these links out now.

              3. 7

                The only issues I’ve heard relate to the command line being inconsistent.

                1. 4

                  while I think git is great at solving a complex problem and aside from the command line being inconsistent, the man pages have been awful for someone not knee deep in the nuances of how it works. For example, the man page of a rebase use to be laughably obtuse at best. It has gotten much better though as now it reads: git-rebase - Reapply commits on top of another base tip, which is about as succinct and clear as you can be for a complex feature.

                2. 4

                  As someone who uses git a lot and has spent time doing fancy tricks with it:

                  • The staging area is inconsistent (in particular in how it interacts with stash) and not useful enough to be worth the complexity budget. I would remove it entirely.
                  • The command line is bad, in particular checkout is horribly overloaded. I would move the functionality of git checkout -- into git reset.
                  • You end up with too many copies of every branch that can get out of sync with each other, made more confusing because git almost-but-not-quite hides your local copy of the remote. This introduces an extra asymmetry where fetch has no converse. I think I would probably remove the local copy of the remote and have an online-first workflow where you can only pull/merge remote branches when you’re online; if you want a local clone of the remote repo distinct from your working repo then set one up explicitly (as a bare repository).
                  1. 8

                    The staging area is inconsistent (in particular in how it interacts with stash) and not useful enough to be worth the complexity budget. I would remove it entirely.

                    Yikes, no thanks! The stage is one of my favorite features. Building up a commit piecemeal is soooo much better than the old subversion commit style that encouraged devs to just throw in every dirty file.

                    1. 1

                      If you’re committing something that doesn’t include every dirty file you’re almost necessarily committing something you haven’t tested, which may well not even build. That’s a big drag when you come to bisect (which is one of the key advantages of git IME).

                      1. 1

                        If you’re committing something that doesn’t include every dirty file you’re almost necessarily committing something you haven’t tested

                        Or, y'know, git stash -k -u && rspec

                        1. 0

                          That’s possible, sure, but when one makes the bad practice easier than the good practice one is going to have a bad time.

                          1. 3

                            There is absolutely nothing “bad practice” about building up a proposed commit, testing the staged commit, and then committing it.

                            It’s certainly a better practice than the “tweaked the renderer, adjusted the logging, added two new export formats, and some other stuff I forgot about” kitchen sink dogshit commits that “commit all dirty files” inevitably leads to.

                            1. 2

                              The bad practice is committing something that doesn’t work. That’s much worse than a commit that contains two unrelated changes (which is not something I see very often - if you’re ending up with that try committing more frequently).

                      2. 1

                        commit --amend accomplishes the same thing with much less confusion.

                    2. 3

                      I like git, but I’ve had the chance to onboard smart developers who are more familiar with mercurial. They’ve made some convincing arguments as to why mercurial is nice to use.

                      I don’t know if the next billion programmers will use git, but I have no doubt they can use git. Most people come out of a 6 week coding bootcamp knowing how to use git and github. That’s a pretty low bar.

                      1. 1

                        My main problem with just about every article I’ve ever seen espousing this sentiment is that it comes along with zero solutions.

                        If you’re going to say “Git is bad.” then you need to also offer an alternate model of collaborative version control that works better. So far I haven’t seen that.

                        1. 3

                          I don’t think that’s true. What you’re saying is that I don’t have the right to say something is bad unless I also have the ability to fix it, which seems ridiculous to me. I hear that a lot with open source software, “if you don’t like it, just fork it and change it!”.

                          Just because I use Git doesn’t mean I know how to write a VCS. There are, however, people who do know how to do that, and I can appeal to them in the hopes that they might agree with me.

                        2. 1

                          Sadly I hear the same quite often as well, our tech leads and architects prefer Accurev over git. While I can see some benefits for accurev, git was dismissed as being ‘too computery sciencey’.

                          1. 4

                            git was dismissed as being ‘too computery sciencey’

                            Speaking as someone who writes software. That’s horrifying.

                            prefer Accurev over git

                            I just googled accurev. My gut reaction was that it looks a lot like a nightmare of a product I was once forced to use called IBM Jazz something.