4 ms·
As the author points out, it is an unnecessary primitive, once you learn about things like commit —amend, which you will inevitably eventually learn about anywa
by inimino 9y ago
As the author points out, it is an unnecessary primitive, once you learn about things like commit —amend, which you will inevitably eventually learn about anyway. Adding redundant ways to do the same thing is not the way to make a tool approachable.
The basic problem is that git was designed to solve Linus’s problems, and Linus’s problems are not your problems. However, because of network effects, most of us end up using the same tool.
- mercutio2 9y agoHow does commit --amend in any way solve the same problem as the staging area? If I’ve got a big change which I want to split into three small internally consistent changes, with each change overlapping in many files, how in the world would --amend help?
- inimino 9y agoIt solves the problem I was directly replying to: > I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go. However, it does not replace all use cases of the staging area, which is why I gave it only as an example. Of course, `commit --amend` with `-p` could solve your problem as well. Alternatively, “create a new, 'pending’ commit, without a commit message, don’t point HEAD to it yet, and change most of the commit-related commands to modify this commit until it is finalized” also solves all the use cases of the staging area, because that is what the staging area is, but it is presented in a much more confusing way and ends up being yet another new concept for git beginners to grasp.
- mercutio2 9y agoFair points. After thinking about this more, I find myself agreeing that in terms of beginner friendliness, the combination of incredible name confusion and the relative paucity of use cases where it’s necessary make the staging area an interesting area for significant change in the git defaults.