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.

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