On: More Productive Git

[jordigh]

The staging area is incidental. It's yet another place in which your code can be, and it confuses users. This is why Gitless has removed it.

https://gitless.com/#vs

You don't need the staging area to select hunks into a commit. The selected hunks could go straight into a commit. Selecting hunks is a different thing than putting the selection into an extra intermediate area between working directory and commit.

You don't need an extra intermediate area to review a commit. Commits are flexible and modifiable, so you can review the draft commit, modify it as necessary, and then publish it.

[tom_ → jordigh]

I always assumed it was there as an analogue of the state tracked by a UI such as TortoiseSVN's Commit dialog, or (though it's a lot longer since I lasted used it...) Perforce's changelists view. It's a list of files you've got checked out or modified: you tick the ones you want in the commit, right click to delete files or revert, double click to get a diff, that kind of thing. Between each deletion/reversion/diff/etc., the state of the tickboxes is retained, so you can sort of just fool about until you've got what you want.

But this sort of multi-step thing is often a pain to do from the command line, I find: unless you have some way of tracking the state between commands, it's no fun working through this list of items, building up a to do list that you then have to get done at the end with one uber command. And the staging area is this way of tracking the state when it comes to putting together your commit.

The gitless examples look to have many common possibilities licked, though, and perhaps that will suffice for most cases?

[cheerlessbog → jordigh]

I didn't know about Gitless. The other interesting thing I see about it is that switching branches also switches out any uncommitted changes. On balance I think I find that less useful.