7 ms·
I love git, but even git checkout is asinine. It's fine for checking out a tag/branch/rev/treeish, but why on earth does it also revert files to their checked i
by ibrahima 12y ago
I love git, but even git checkout is asinine. It's fine for checking out a tag/branch/rev/treeish, but why on earth does it also revert files to their checked in state if given a path argument?
I don't think git should be prone to trashing local state due to how it usually yells at you when it's about to do that, but then I've been working with a student this quarter who seems to do that every time I push something to github and she needs to pull. I think if the git community got together, did a usability study on how people actually use git, and renamed/split out commands into names that made sense, it would be a huge boon for general usability.
- kazinator 12y ago> why on earth does it also revert files to their checked in state if given a path argument Simplification! :) "git checkout file" reverts a file from the index. If it doesn't exist in the index, then from HEAD. The problem is that you can make a typo, because branches, tags and files are all in the same namespace. Suppose you wanted to type "git checkout foob" which is a tag or branch, but instead you make a mistake and type "git checkout foom" which is the name of a file that happens to have unstaged changes. Oops! If "file" has unstaged changes, then "git checkout file" should rename it out of the way first to "file.#1#" or whatever. (Hello, look at CVS!)