influenced by this [blog post](http://www.saintsjd.com/2012/01/a-better-ui-for-git/) and this [fantastic diatribe](http://stevebennett.me/2012/02/24/10-things-i-hate-about-git).
There are a lot of really terribly named commands here: add, reset, checkout. (checkout? What is this, SVN?) They are probably named so because they are seen from the point-of-view of the stage, rather than the working directory. But since the stage is a new concept to beginners, thinking from the working directory point-of-view is how most new users (or even most normal developers) think.
So here is where I make perhaps the biggest naming changes. Updating the stage copy of a file is now `stage` as a verb. Reseting the stage copy is now called `unstage`. `get reset` now resets the file in the working directory, rather than the file in the stage.
Here I mostly just enhanced the porcelain commands. At some point, I would like to consolidate the syntax for creating and deleting things, where things can be branches, tags, remotes, etc.
get | git equivalent
--- | --------------
get commit | Prompts for commit message inline, rather than opening a text editor
get commit *message* | git commit -m *message*
get undo commit | git reset --soft HEAD~1
get branch *branch* | stashes working tree, creates or switches branch, and checks out branch
get rmbranch *branch* | git branch -d *branch**TODO: rename?*
get tag *tag* | git tag *tag*
get untag *tag* | Deletes local tag and shows Y/N prompt to delete remote tag.
#### Viewing changes
By default, all diff commands compare the working directory to something else. By default, that something else is HEAD, not the stage as it is in git, because I think the most common query is "what have I changed since my last commit?" not "what is different between the stage and my working directory?". STAGE refers to the git staging area. I choose to always use the keyword *stage* rather than *index*, because they're the same thing and having two names for the same thing is unnecessarily confusing. And calling it the *cache* in the --cached option just makes it even worse. I avoid the stage/index/cached confusion by choosing to give it a name (STAGE) and treating it like a special reference akin to HEAD.
get diff *ref* | compare working tree with *ref* (git diff *ref*)
get diff STAGE *ref* | compare stage with *ref* (git diff --cached *ref*)
get diff *refA**refB* | compare *refA* with *refB* (git diff *refA**refB*)
#### Working with remotes
Here, I want practicality and "it just works (TM)". The clone command installs submodules by default. I am (slowly) adding support for popular hosting services. Right now its just Github but I will probably add Bitbucket.
The biggest grievance when working with remotes is the "git pull" command. Which as anyone will tell you, just does "git fetch" followed by "git merge". But merging can be downright dangerous, especially if you have unsaved changed, leading to unsuccessful "git pull" attempts. I am going to avoid "pull" altogether, but to speed things up, my "fetch" operation goes ahead and fast-forwards branches.
I started this project because `git log --no-pager` gives an error. Apparently I wanted `git --no-pager log`. This was the last straw.
*So I decided to "fix" the git CLI.*
EDIT: Even better example of inanity of git CLI: To get the SHA reference of HEAD, do you use `git show-ref HEAD --abbrev --hash` or `git rev-parse --short HEAD`?
* Why are they different results?
* Why does `show-ref` use `--abbrev` but `rev-parse` use `--short`?
* Why are the options _after_`HEAD` in `show-ref` but _before_`HEAD` in `rev-parse`?
* I leave answering these questions as an exercise to the reader.
