The git command-line interface sucks
When I use git, I'm scared I'll break something. I just talked to an open source celebrity who has used git for 3-4 years who avoids using the CLI because he's afraid he'll break something, and uses Tower when possible. I recently had a client accidentally delete their work because they didn't understand git. My fear of breaking something is well-founded.
You can't put a price on the confidence that source control is supposed to give you. That confidence suffers when people are afraid of causing irreparable damage during normal use.
This article lists a few ideas on what git can do to improve.
A Controlled Vocabulary
These are all the same thing:
- Directory cache
- Current directory cache
- Staging area
- Staged files
The maintainers of git need to decide which is correct and reject all other terms in APIs, CLIs, and documentation.
Who is This Documentation For, Anyway?
A lot of the git documentation was written as if the audience is people who already understand the material. This means the documentation is useful for reference but useless for learning. Documentation should be good for reference and for learning.
Example from this source:
git-push – Update remote refs along with associated objects Here’s a description for humans: git-push – Upload changes from your local repository into a remote repository
Changing History Is Scary
The ability to change history is nifty, since it lets you prune quirks and delete accidents. It also makes some people nervous, and still other people believe it is a flaw in git.
Regardless of how you feel, let's recognize that the ability to cause irreparable damage can be scary. Git's CLI doesn't make it especially clear what will change history and what won't. Git should separate out this kind of functionality into separate commands, rather than something that can happen if you use the right flags.
This has been done to death, but here are a few that I think are important:
git push should push the current branch only
git pull should
git add <paths> and
git reset <paths> add and remove files from the staging area. They should be named
git add and
git remove or
git stage and
git unstage or something that makes their relationship clear.
This might mean breaking
git reset into separate commands that do different things. This is a good thing.
Learn From People Who Don't Tolerate Bullshit
Some smart people who don't tolerate bullshit have made their own git command-line tools. The maintainers of git should take some pages from their playbooks, work with them, or even integrate.
I use git and github and will for the foreseeable future because the pros outweigh the cons. The fact is, the pros are pretty damn badass, to be able to outweigh cons like these.
But this stuff needs to be fixed. I'd rather fix and unify the community around git than see things fractured by alternative CLIs and competing SCMs.