Hacker News Reader

This article isn't complaining about the UI. They are very specifically attacking the /concepts/ that git uses – see the quote I posted further down in this thread.

It appears as if the complexity of git has created a sort of Stockholm-Syndrome, where people mistake the flaws of the system for symptoms of its magnificent power, and dismissing all criticism with an attitude of "let the hobbyists have something with a shiny GUI, this a tool for professionals".

But what people are asking for is /not/ a shiny veneer hiding the complexity, but a rethinking of the concepts that git uses. "Concept" here means mostly the mental model people form of how git operates, but that is often linked to the terms used and the internal structure.

As an easy-to-grasp example, filesystems generally operate with the "tree" concept. Note that there's nothing mandating such a structure – you could create a fs that's based on tags instead. Or weaken the tree metaphor by allowing cross-connections (i.e. linking). But given the choice of one concept, it creates certain assumptions about how to operate the system. And when those break down, people rm -rf and start over. Way to often.

True that they focus on concepts. The thing is, the overview diagram of git concepts on that page (which is in turn taken from the gitless paper) doesn't even mention commits as a separate concept even though they are one of the most important concepts of git (and the ability to quickly juggle commits is crucial to the original git workflow).

That makes me a bit sceptical about whether the authors really thought through all the various use cases of git, i.e. those 5% that the GP comment talks about, and about their conclusions.

The article points to a specific feature that once removed...

> “the elimination of the staging area was enthusiastically received as a major reduction in complexity.”

But I'm using it regularly. This is the feature that makes git stand out, even for casual users who typically edit things then commit (and have to sort things out to make sensible, semantic commits instead of "whatevs"). Every single tutorial glosses over it, but it's the single most important feature that hinges on what git is and how it operates at its core.

Every time I teach git, I take great care explaining why and how the staging area (the index and git objects, really) works. Every single time I explain that you're preparing a transaction that you end up committing (with all relevant — but obviously wrong — database or journalling filesystem analogies). And every single time, it just clicks.

The staging area is incredibly useful. It's not the functionality that's the problem, it's the interface.

To design a great interface, first you have to come up with a good metaphor and a great name. That's the first obvious fail, because the staging area has at least three different names in common use. As you said yourself, once you use a metaphor to explain the staging area, it just clicks. With a good name, the metaphor should be obvious.

And then you have to supply a consistent, non-surprising interface. What's the staging area? It's essentially a commit-in-progress. So why does it have a different interface than git commit --amend?

Grumpy me is really disappointed that git itself subsumed the porcelain. There were some really good ideas floating out there that fell by the wayside as git became usable by itself.

Stacked Git, for instance: http://www.procode.org/stgit/

We should have had a bunch of porcelains that evolved to a nice shine. You should have been able to switch back and forth between porcelains.

> What's the staging area? It's essentially a commit-in-progress

Aha, that's where the typical view of VCSes shows through the cracks of our old habits: here commit is not an object, it's an action. So there's no "commit-in-progress" because either you commit or you don't, and the operation is virtually atomic. The fact that object with badcafe sha1 records the history of that action and is called "commit badcafe" in the log is incidental, and we're being abusive when we're literally saying the commit is the object.

So when you say git commit --amend, it's really no different than git commit, because you're just telling it to do the very same thing, only with a git reset HEAD^ before that.

That said, I'll readily admit the UI is poor, mostly because it's grown, not designed.

In my view of git, commit is very definitely an object, the action is 'creating a commit object'.

I don't think either of us is wrong, we just use different names, making communication very difficult. Which just underscores my original point. Names matter.

> We should have had a bunch of porcelains that evolved to a nice shine. You should have been able to switch back and forth between porcelains.

That's basically what Magit is, a porcelain for git. It actually adds operations beyond what git's own porcelain allows, and makes easier the ones it does allow. Using Magit is like being a git ninja compared to using the CLI.

True, I love magit. Most people here in the office use magit or one of the available GUI's. But none of them change the underlying metaphor in the way that stacked git did.

> But the reason git beat out the competition isn't git's excellent UI or large marketing budget, it's that those features actually provide significant value.

I tend to think that the reason git beat out the competition is github. It was the first VCS hosting service that actually provided a sane UI that enabled non-vcs-experts to at least observe what's happening. github doesn't provide an interface to a lot of gits features and so do the github-provided native clients, but they are sufficient for at least 50% of the population that I know. Many people don't know and/or don't care about all the other power_features that git provides.

Relatedly, how awful is Launchpad? I can never get anything done there. It's as if they got the most brilliant UI designers and told them to make something completely unusable. I cannot believe a UI this confusing and opaque was made by mistake. I regularly end up navigating around in circles looking for the thing everyone wants most in a repo: The code.

Are they really so brilliant then? Seriously though, I think Launchpad was designed less for managing code and more for managing a bureaucratic project. While individuals and projects can use it, it's primarily only useful for Ubuntu and their particular workflows.

> But the reason git beat out the competition isn't git's excellent UI or large marketing budget, it's that those features actually provide significant value.

I don't know if it's true for everyone, but this is at least true for me. The reason I started to work on a git remote helper to talk to mercurial servers is that I grew frustrated that mercurial didn't have some of those features (and that the existing git remote helpers were not working well at the scale of mozilla-central, or required a local mercurial clone under the hood)

And funnily enough mercurial is today the most scalable of the two. As an example Facebook uses it for it's monorepository. Not sure about the scalability of of git-helpers though.

What features were you missing, by the way? Mercurial has had rebase, squash and light branches (bookmarks) for many years now. I personally don't miss staging if I use it.

Not to knock Mercurial, but didn't Facebook have to apply a lot of custom changes to get it to scale up? Not sure if those were committed back.

https://bitbucket.org/facebook/ not for these at least

> Not sure if those were committed back.

Some were for sure: [1]

1: https://selenic.com/hg/log?rev=fb.com

> the reason git beat out the competition isn't git's excellent UI or large marketing budget

I'm most inclined to believe that it certainly was git's large marketing budget that got it to where it is today. Not a monetary budget, but its reputational budget: "Written by Linus" so it must be good.

And github's $100 million in venture capital didn't hurt.

So Git needs its LaTeX?

I think it already does: Magit. :)