I kinda conceptually disagree with approaches like this, for the same reason I dislike the official Github client: it renames some basic git concepts. e.g. git sync. How is this helpful when the dev is put in front of a situation (not configured server, new colleague who is not aware of legit)? Essentially I admire the work put into this project, I just question the goal.
In the general case, I agree. But working with Git you will very probably have to learn what's going on beneath the abstraction sooner-or-later (ie. when I'm working on a team larger than 1 person and the repo becomes a mess). So writing abstraction layers just increases the number of things that need to be learned.
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.
Not really a new idea ... but to be honest, the naming of some of the commands are equally vague to new users as the default git commands. Harvest, sprout, graft?
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.
I completely agree with your first point, but I do think that the majority of people using git probably don't have more than a single remote. I am sure there are those few people that are tasked with pulling (and hopefully, pushing) to the upstream, and likely a deployment remote like Heroku probably exists behind some process or script.
My thinking about this may be seriously flawed in some way, but couldn't the official Git implement these command names or something similar as an alternative to the currently supported commands without any problems?
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?
Looking over the commands, I thought, "Wow, this is really useful." Then the creeping dread hit. It's the kind of dread that comes along with having worked with computers for a long enough period of time: What happens when the project is eventually neglected and I am left high and dry scrambling to unlearn all of the neat shortcuts that I've come to rely on?
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.
In these cases doesn't the value in "Wow, this is really useful." completely outweigh the cost of having to learn something else if it does go away? It's not like you have a finite set of things you can learn and then that's it, brain's full.
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.
I've used git for almost a year and it's still furiously unfun to interact with. It's not easy, it's not transparent, and it's not intuitive. You need to really, deeply understand git in order to use it. I don't want to really, deeply understand git any more than I really, deeply want to understand rsync. It's a tool. I just want to use it.
Well then you are just awesome. For anyone who has been using various source-control systems for many years, its commands are not intuitive, and cause unnecessary friction. Unfortunately, as elsewhere in life, the best tech does not always win, at least in the short-term.