Why is that important given that you can do exactly the same with a commit in the local tree?
I haven't read the paper, but the last paragraph in the article makes me a little sad. Then again, there were hardly any progress that wasn't met with significant resistance initially. (EDIT: typos)
It comes down to levels of "written in stone"-ness, for lack of better words. There's a hierarchy of how much thought and effort change requires at various levels, starting at requiring no additional thought, to requiring considerable thought, and maybe even coordination with others:
- changes on hdd
- changes in staging area
- changes in commit
- changes in commit that came before a recent commit
- changes in pushed commit
I'm not entirely sure about the following, and i think it merits more thought, but here's my current state of mind about it:
Technically you could do the same as the staging area by forcing the user to create a new, empty, but named commit when they decide they're done with the last one, and have all the current staging-affecting commands affect the last commit instead.
However, for one, i think it may be easier to mess up and lose data unexpectedly when workign that way, and for the other, putting down a name for a commit when you're not even sure what it's gonna be may be an awkward way of working. Lastly, you'd also need to implement "empty" commits. I'm not sure how useful/easy that would be with git.
Empty commits already are supported (see --allow-empty). And you can rename that commit at will using --amend, so the first name could simply be a placeholder - like "staging" :)
I haven't read the paper, but the last paragraph in the article makes me a little sad. Then again, there were hardly any progress that wasn't met with significant resistance initially. (EDIT: typos)