1. 19

  2. 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:




      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. 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.

                      3. 26

                        I fundamentally disagree with the premise.

                        The next billion programmers won’t have computer science degrees or speak English. They’ll be on Chromebooks, or their phones. They’ll touch code in smaller ways and it will only be a part of their job: they might be considered marketers or analysts or designers. And they may not use Git or Github.

                        These people already exist, they aren’t programmers, and their interfaces are not going to change to look more like programming. They’re going to have version control, but it’s going to look like video games or Google Docs with a mix of auto and manual save points.

                        1. 9

                          Exactly what I was going to say. The introductory sentence is totally contradictory. The author basically says “The next billion programers won’t be programmers.” Well, then they aren’t programmers. And the author is right, non-programmers don’t need Git. But programmers do.

                          And the trend in version control software if you draw a line from VCS to SVN to Git is for more features and more capabilities, not less.

                        2. 9

                          There are some confusing things about this article, not least of which is the title. But if I understand it correctly, the author is basically saying that GitHub could do more than they’re doing now to make Git easier to use, perhaps even retooling Git altogether.

                          I don’t see this happening any time soon; while Git may take some patience and practice to learn how to use correctly, GitHub is still primarily targeted toward developers, who are mostly used to work with non-simple tools (see Webpack), and besides, their whole infrastructure is based on Git.

                          That said, GitHub’s mission has always been to provide a visual, more pleasant way to use Git, and as a side effect, they’ve enabled less tech-savvy people to use it, too. As an example, at my last job we were able to teach our office managers, none of which knew what Git even was, how to use GitHub. And it worked fine.

                          Then again, perhaps GitHub as a product and company have stalled. Maybe it’s time for some other product to take up the reins.

                          1. 3

                            GitHub and git are not the same thing, but confused very often. I’ve met developers who don’t know you can easily host git yourself and that you can have multiple remotes.

                            1. 1

                              Interesting thoughts, i actually think the next VCS will emerge from the product, so a company like Github would create a new version control system that is git compatible and fix the shortcomings of modern DVCS like binary handling lack of complex permissions on file level.

                            2. 9

                              IMO this is nothing more than a frustratingly content free splash piece.

                              I don’t see anything at all insightful in this article. IMO the conclusion says it all - he’s investing and wants to raise capital.

                              1. 7

                                Perhaps they won’t be using git, but git is a major improvement over mks, svn, and the rest.

                                Quite frankly, i like how git is modeled after a data structure and its operations are about manipulating that data structure. There are limitations to the choice of structure, but as an engineer, i appreciate that. It is elegant in its nature.

                                I believe that people’s limitations to understanding git are due to taint more than anything. We have become accustomed to programs working a certain way under a certain model. Let’s call this user driven stories. Git is more like algebra: the tools and operators to describe an idea. I’ve always appreciated math and it’s elegance and come to hate “human logic” as common intuition isn’t always so common. I often struggled with MKS and Windows because there is so much “crap” in the way. I do not have the time nor the interest to learn and relearn a thousand different apps and api’s for my job. With GIT, i really only have to remember to think in terms of commits as nodes in a graph.

                                1. 6

                                  Huh. Things that the author thinks the next github will need.

                                  designing the interface in a task-oriented manner

                                  I often find people spout this sort of crap shortly before a perfectly usable interface gets forked into a weird non-ergonomic workflow.

                                  Assume all code is online, all the time

                                  How about we don’t? The next billion programmers will have crappy, intermittent, low bandwidth connections. Unless Elon Musk succeeds ; ). I live a very first world life and I still have to deal with a combo of ISP outages, flaky VPNs, expensive plane wifi connections, cell deadspots, etc. One of the most sucessful “cloud storage” companies out there (dropbox) relies primarily on local synchronization. I really hope future tools don’t assume all code is online all the time.

                                  Invest in Github’s people network

                                  Cause and effect have been confused. Github has become popular as a linkedin for programming because it contained open source work. Sure, github could get more traffic by copying some of linkedin’s patterns but a new company that attempts to be “github without the open source progammers” is gonna have a tough time.

                                  Invest in Github’s code network

                                  Well. This isn’t so bad. It’s been done in a somewhat ad-hoc manner by various language tooling already. I can go get a library off github. I can add a git uri to a python pipfile.

                                  1. 5

                                    I agree that the proper use of git commands is difficult to teach to new users (my students will second this), and there are things I would change if I were in charge. But I think it is incorrect to assume that most users are constantly online. There are billions of people with inconsistent internet access or access that is limited in certain ways. I’m not saying git is forever, and I look forward to a superior alternative. But he sounds like he’s trying to turn git not making assumptions about your internet access into a flaw. For many that’s perfectly fine or a welcome feature.

                                    1. 2

                                      It’ll be a while. I think about how many companies are still on CVS/SVN etc..

                                      The problem space is tough, tough to envision the next big paradigm shift.

                                      1. 2

                                        Git is great because it’s model is simple but you can do so many powerful things with it. This in turn makes the user interface complex.

                                        The article mentions some kind of always synced online versioning system. This sounds like the author doesn’t quite understand why the distributed nature of git makes it so great.

                                        Maybe something more integrated like Fossil is the future. GitHub already includes bug tracker, wiki, and a pull request workflow. This all belongs together many times.

                                        1. 1

                                          Git is great because it’s model is simple but you can do so many powerful things with it. This in turn makes the user interface complex.

                                          I disagree very much. Specifically, Git and Mercurial have essentially the same data model. If that implied a complex interface, Mercurial should have a complex UI, too. Instead, I rarely hear Mercurial’s UI accused of needless complexity, especially not when compared to Git’s.

                                          This is the model at the core of both Git and Mercurial:

                                          • History is a directed acyclic graph
                                          • Every commit, or changeset, consists of:
                                            • a bunch of changes to files
                                            • a pointer to the parent commit (multiple parents for a merge)
                                            • metadata (committer name, commit message, etc)
                                            • a hash of all the above: the commit’s id.
                                          • A checkout at commit X is the ‘sum’ of X and all its ancestor commits, which you can find by walking the DAG.
                                          • You share history by pushing/pulling commits that unknown to the receiving repository, expanding your or their history graph.
                                          • You keep your place using moveable branch labels. (Mercurial calls them bookmarks, to emphasise their ‘moveable pointer’ nature.)

                                          The data model wasn’t always this similar: Mercurial started out with named branches that were part of a commit’s metadata, and which could not be deleted. But now that we have bookmarks – the model is so much the same that Mercurial and Git are interoperable. With the right extensions, your data can make a round trip and come out the way it was. Hg-git lets you talk to Git repos from Mercurial; Cinnabar lets you talk to Mercurial repos from Git.

                                          There are, beyond this, a bunch of differences between Mercurial and Git repositories, sure; but all of them are either warts they could remove, or features (sometimes major features) the other one could have, too, or quirks incidental to the implementation.