Better to fork+rename git.
Spending time generating aliases for commonly used commands and scripting commands together to form new (possibly more comfortable) command-wording are both fine once you use the product enough to learn which aliases and scripts would be productive.
Providing a set of these alternatives as a wrapper is a dangerous alternative to newcomers, and has the potential to simply add confusion.
I think these efforts must come after foundational product knowledge is achieved, not before. This effort seems to target those who do not yet have said knowledge.
I really think git could use a simpler and more understandable api for the entry level commands pull/checkout/rebase/... but this isn't really helping alot except for perhaps the switch and (un)publish commands.
1. Only 1 git remote? I need at least `master` and `heroku` for all of my projects, and often I'll need one or two extra `github` remotes for other forks/collaborators.
2. I wish it had pictures of what exactly it was doing (git graph-style stacks of commits before/after each commit).
Strong disagree. Nowadays the majority of git-users probably interacts with github.
Just count the number of "Fork me on github"-ribbons that you come across on any given day.
The github workflow for forking a repository involves two remotes (origin and upstream).
Heck, why not even label the current Git commands as "legacy commands" and leave them supported "forever", but officially change to more user friendly and logical command names such as this?
It's probably TextMate's fault as well as Apple's—the latter of which seems to get a perverse kick out of jettisoning things people rely on—but, I am increasingly leery of anything that has even the most remote chance of leaving me high and dry.
Just use it until it stops being awesome and then use something else. Life's too short and your time is too valuable to pass over things like this, where your gut feeling is probably correct.