3 ms·

I completely agree. Some commands are not intuitive at all. I always wanted git stage [file], git unstage [file] instead of add and reset. I totally understand

I completely agree. Some commands are not intuitive at all. I always wanted git stage [file], git unstage [file] instead of add and reset. I totally understand why those were chosen when the original code for git was written but I really think it's time to re-evaluate the CLI and do better.

vjk800 3y ago
This would make a lot of sense actually. It would also remove the confusion new people often have over what does it mean for changes to be staged
- kazinator 3y ago
  Git's documentation should somehow prominently teach people that: - Git stores snapshots, not changes. - Snapshots go into something called an index. "Git add" means to add to an index. - A new commit is prepared by creating a new index based on the index of the HEAD commit. This new index is the "stage". The index holds a complete copy of the files. When you stage only certain changes with "git add --patch", that is still the case: you're making a version of the file which has only those selected changes and that goes into the index. A built-in tool that is external to the git representation did the text manipulation to separate those changes. - When you commit, the uncommitted index you have created as a stage becomes a commit.
  - sshine 3y ago
    That's a good explanation. I've copied it to a colleague who is learning.
adhesive_wombat 3y ago
I think the Git maintainers realise that and introduce commands like "restore", even though the action can be (and was for a long time) achieved with the original command set. Also I believe "git stage" exists too: https://git-scm.com/docs/git-stage https://git-scm.com/docs/git-stage Because git commands are used in a bajillion scripts, it's very hard to remove "excessive" functionality from the old commands even when that would improve the orthogonality of the tools.
kazinator 3y ago
Those could be add and rm, if rm by default didn't remove the working file. Git should eliminate the following redundant naming: stage, cache, index all refer to the same thing. If I want to diff between the working copy and the stage, why isn't it "git diff --stage", but "git dif --cached"? A cache is something for fast lookup; the index isn't a cache; it's the permanent record of stuff in version control that will become a commit. When you invalidate a cache entry, the semantics is unaffected, only speed of access. Removing from a git index is semantically significant.

vjk800 3y ago

This would make a lot of sense actually. It would also remove the confusion new people often have over what does it mean for changes to be staged

kazinator 3y ago
Git's documentation should somehow prominently teach people that: - Git stores snapshots, not changes. - Snapshots go into something called an index. "Git add" means to add to an index. - A new commit is prepared by creating a new index based on the index of the HEAD commit. This new index is the "stage". The index holds a complete copy of the files. When you stage only certain changes with "git add --patch", that is still the case: you're making a version of the file which has only those selected changes and that goes into the index. A built-in tool that is external to the git representation did the text manipulation to separate those changes. - When you commit, the uncommitted index you have created as a stage becomes a commit.
- sshine 3y ago
  That's a good explanation. I've copied it to a colleague who is learning.

adhesive_wombat 3y ago

I think the Git maintainers realise that and introduce commands like "restore", even though the action can be (and was for a long time) achieved with the original command set. Also I believe "git stage" exists too: https://git-scm.com/docs/git-stage https://git-scm.com/docs/git-stage Because git commands are used in a bajillion scripts, it's very hard to remove "excessive" functionality from the old commands even when that would improve the orthogonality of the tools.

kazinator 3y ago

Those could be add and rm, if rm by default didn't remove the working file. Git should eliminate the following redundant naming: stage, cache, index all refer to the same thing. If I want to diff between the working copy and the stage, why isn't it "git diff --stage", but "git dif --cached"? A cache is something for fast lookup; the index isn't a cache; it's the permanent record of stuff in version control that will become a commit. When you invalidate a cache entry, the semantics is unaffected, only speed of access. Removing from a git index is semantically significant.