Git needs help

gistfile1.md

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

Git needs a controlled vocabulary, which is a fancy way of saying "Stop Using Different Words For The Same Thing".

These are all the same thing:

• Index
• Cache
• Directory cache
• Current directory cache
• Staging area
• Staged files

source

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.

Sensible Defaults

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 --rebase

Symmetry

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.

• Easy Git
• hub
• legit
• etc

Conclusion

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.

Additional Reading

• Git Koans

Perhaps I can help ease some of it.

plop these in your home directory's .gitconfig

[alias]
  stage = add
  unstage = reset

pull --rebase as default is just a bad idea, it can totally trash your local branch if it turns into a bad merge

Also, you should never actually NEED to pull --rebase if you are working in branches like you should be with git.

The "changing history" thing is somewhat protected when you use the CLI because you can't force push on accident... I feel like if you use the GUI you have these problems

git push should push the current branch only

maybe you should try: git config --global push.default simple
this is the implicit default behaviour of the git 2.x

Changing History Is Scary

True.

git pull should --rebase

But rebase does change history...