9 ms·

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 m

• Mithaldu 10y ago
  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.
  • icebraining 10y ago
    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" :)