3 ms·
I agree with most points. But I violently disagree with "Git is easier to learn". I love git, but its command-line is just horribly designed: * git reset on f
by Peaker 16y ago
I agree with most points. But I violently disagree with "Git is easier to learn".
I love git, but its command-line is just horribly designed:
* git reset on files takes them out of the index, whereas without files, it moves the current HEAD to a different commit. It should be split into 2 commands, and the command that does the opposite of "add" should be named "unadd".
* Similarly, git checkout on files overwrites their content from some revision, whereas without files, it moves HEAD to a different branch. It should be split into two commands.
* The git guys should decide what the staging area is called, and use that same name everywhere. Not "Staging area" in most docs, "Index" in most commands, "--cached" in diff.
* It is very difficult to lose your committed work in git. But there are too many ways to accidentally lose your uncommitted work in git: "git reset --hard <refspec>" (which is pretty useful for purposes other than losing your work). "git checkout .", "git clean -f", ... Irreversible loss of work should not be so easy, and should have interactive prompts defending it, or preferably just not be irreversible.
* git "push" and git "pull" sound like they should be opposites, but they aren't. Many such bad naming choices plague git's command set.
* Rename a branch? "git branch -M". Rename a remote? "git remote rename". Be consistent!
And the list goes on and on...