Legit: Git Workflow for Humans(git-legit.org)
git-legit.org
Legit: Git Workflow for Humans
http://www.git-legit.org/
26 comments
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.
Agreed. I don't use git, because I know that I would write wrappers for commands to be saner like SVN or mercurial and that is the wrong approach.
Better to fork+rename git.
Better to fork+rename git.
It's just a shortcut. The underlying operations haven't gone away. Abstractions are good.
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.
My point exactly.
Agreed.
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.
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 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.
The nice thing about those is that they create new terms rather than using terms that exist in other VCSes but mean something very different.
Looks nice. The two biggest problems I have based off the README, in order:
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).
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).
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.
I do think that the majority of people using git probably don't have more than a single remote
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[1] involves two remotes (origin and upstream).
[1] https://help.github.com/articles/fork-a-repo
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[1] involves two remotes (origin and upstream).
[1] https://help.github.com/articles/fork-a-repo
Just use 'git push heroku' to deploy then. Legit doesn't break existing git commands.
Exactly.
When I first encountered git, I had a hell of a time learning how to actually control my source. Legit would've been a great gateway drug.
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?
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?
Then, I'll have to relearn all of the traditional methods that aren't going anywhere. Normally, I'm not a uptight about this stuff, but it's the same reason that I can't bring myself to switch from JavaScript to CoffeeScript despite the fact that I _really_ like the syntax.
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.
Then, I'll have to relearn all of the traditional methods that aren't going anywhere. Normally, I'm not a uptight about this stuff, but it's the same reason that I can't bring myself to switch from JavaScript to CoffeeScript despite the fact that I _really_ like the syntax.
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.
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.
Too legit to git!
I really like this. I have trouble with git - it is not my first VCS, and many of the command aliases that it uses are not intuitive or do something very different from what they do in other VCSes.
i don't think anyone who used git daily for a month has problems with the original command names. i used git before svn and now i'm totally unhappy with the svn-command-names...
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.
It took me a day to get to the point where I understood the internals of git well enough to be comfortable using 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.
Previous discussion: http://news.ycombinator.com/item?id=3752447