5 ms·

The issue here is that git is: 1) A tool for managing collaborative work through a beautiful distributed graph theory tree model[1]... 2) ...with a very, very

by Lazare 10y ago

The issue here is that git is: 1) A tool for managing collaborative work through a beautiful distributed graph theory tree model[1]... 2) ...with a very, very difficult to use UI. Unfortunately: 3) A good, intuitive UI for manipulating the underlying model without ignoring edge cases or removing functionality is extremely difficult, and indeed, nobody has done it yet. So you periodically see these articles pop up decrying the UI, but nobody ever makes a great UI that wraps the underlying tools. This article talks positively about gitless, and it's a great tool, but it gets a good UX only be hiding/disabling large chunks of functionality. And like most tools... 4) Git suffers heavily from the 80/20 rule[2]. I'd say 95% of the time, I'm using maybe 5% of git's features. But the other 5% of the time, I'm using another 1% of git's features but it's always a different 1%. I might go weeks without needing to cherry pick a commit, but when I need to, I really need to...and gitless doesn't support it (or most other "complicated" features). 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. And so we get a slow drip of articles like this. "Man, it would be nice if there was a better git UI that had all its features!" It would indeed. [1]: https://xkcd.com/1597/ https://xkcd.com/1597/ [2]: http://www.joelonsoftware.com/items/2006/12/09.html http://www.joelonsoftware.com/items/2006/12/09.html

glandium 10y ago
> 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)
- jbergens 10y ago
  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.
  - KingMob 10y ago
    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.
    - develop7 10y ago
      https://bitbucket.org/facebook/ 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 https://selenic.com/hg/log?rev=fb.com
Xylakant 10y ago
> 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.
- StavrosK 10y ago
  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.
  - alphapapa 10y ago
    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.
matt4077 10y ago
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.
- nhaehnle 10y ago
  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.
zouhair 10y ago
So Git needs its LaTeX?
- alphapapa 10y ago
  I think it already does: Magit. :)
lloeki 10y ago
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.
- bryanlarsen 10y ago
  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/ 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.
  - lloeki 10y ago
    > 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.
mikro2nd 10y ago
> 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.
- doozy 10y ago
  And github's $100 million in venture capital didn't hurt.

by Lazare 10y ago

glandium 10y ago

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

jbergens 10y ago
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.
- KingMob 10y ago
  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.
  - develop7 10y ago
    https://bitbucket.org/facebook/ 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 https://selenic.com/hg/log?rev=fb.com

Xylakant 10y ago

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

StavrosK 10y ago
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.
- alphapapa 10y ago
  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.

matt4077 10y ago

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.

nhaehnle 10y ago
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.

zouhair 10y ago

So Git needs its LaTeX?

alphapapa 10y ago
I think it already does: Magit. :)

lloeki 10y ago

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.

bryanlarsen 10y ago
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/ 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.
- lloeki 10y ago
  > 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.

mikro2nd 10y ago

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

doozy 10y ago
And github's $100 million in venture capital didn't hurt.