4 ms·

The article points to a specific feature that once removed... > “the elimination of the staging area was enthusiastically received as a major reduction in comp

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

by lloeki 10y ago

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