I like git a lot, but find that the more I hear about it, the more pitfalls I discover. The actual user interface often does not seem to have good defaults and just generally does things differently from how I expect.
So. I love that github is working to take you out of the command line. It is fabulous that they are working to make git easer to use at the same time as providing hosting space.
Like Linux, git is taking a while to "mature" from a user's perspective. It's ludicrously powerful -- it's as much as file system as a distributed VCS -- and its 1,001 options need to be distilled for the masses into the handful and a half of essentials.
It's worth contemplating that Linus doesn't hang around defending git. He put it out there -- bless him -- and let it take on its own life. And its destiny is up to us.
git doesn't need to be taken out of the command line. That's where its true power lies, as with all *nix tools. The fact that github can do so much with it is because of this feature, not because they are changing it. That's a powerful thing, and a testament to Linus' design of git.
I bet Linus never envisioned github when building git. And that something so revolutionary -- and I do think github is revolutionary, albeit for a niche of geeks -- should come out of such a development is testament of git's design.
Sure it's a hard package to master -- I haven't -- but whatever you want, and a lot more, is there if you need it. And no-one yet, to my knowledge, has complained that git killed their project.
Well said. When I talk to people at conferences and whatnot about GitHub, they're often surprised we run a core git stack with few modifications. Repositories are stored as plain old git repositories and we use git's normal command line interface for many types of operations.
It really is a testament to git's design (and I think maybe classically designed UNIX programs in general) that we've been able to do so much on the server with something designed mostly for local command line interaction.
People still talk about git's "lack of extensibility" (i.e., no library / you can't write extension programs in Python) but I've found that the "write programs that do one thing" model lends itself extremely well to all kinds of unplanned and novel uses.
I get the same impression from all the git-related submissions. It's like I'm being told that "this car is great. Just remember to jerk the door handle when you open it, give the window a nudge with your elbow before you open it, and the wipers will work extra well if you enable air-conditioning at the same time.
It makes it sound like default, basic git is either broken (merge/rebase) or very constrained for general purposes.
I think it also has to do with the fact that "productivity" tips are conflated with getting-it-right articles. You don't need to alias all commands for git to work, even though it might help your workflow - or not; YMMV.
I've spent a lot of time thinking through this problem. I agree Git is broken. So is Mercurial, Bazaar, subversion and CVS — they're just different flavors of broken (as in they each taste less broken to different groups of people).
Version control is inherently a difficult problem to conceptualize. Distributed version control is probably the biggest step forward VCS have ever seen — but it comes at a price of added complexity on top of a complex subject as is.
But then again that's why I don't focus on "making git better" — I try and focus on making collaboration and source control better. Stop trying to build aliases or tweaks to git's command line... and maybe try and build a great source control tool that just happens to use Git as it's storage engine.
easygit uses real git commands, so you don't need to unlearn anything when graduating to git. It has safer defaults and extra sanity checks (like checking for unstaged changes when committing). The help messages are more verbose and use more consistent terminology than git's man pages. For example, easygit always uses the term "staged" instead of "index/staged/add/hard/soft/mixed/cached/HEAD/etc." And `eg revert` behaves the same as Perforce, SVN, and Mercurial revert.
Comments
I like git a lot, but find that the more I hear about it, the more pitfalls I discover. The actual user interface often does not seem to have good defaults and just generally does things differently from how I expect.
So. I love that github is working to take you out of the command line. It is fabulous that they are working to make git easer to use at the same time as providing hosting space.
Like Linux, git is taking a while to "mature" from a user's perspective. It's ludicrously powerful -- it's as much as file system as a distributed VCS -- and its 1,001 options need to be distilled for the masses into the handful and a half of essentials.
It's worth contemplating that Linus doesn't hang around defending git. He put it out there -- bless him -- and let it take on its own life. And its destiny is up to us.
git doesn't need to be taken out of the command line. That's where its true power lies, as with all *nix tools. The fact that github can do so much with it is because of this feature, not because they are changing it. That's a powerful thing, and a testament to Linus' design of git.
I bet Linus never envisioned github when building git. And that something so revolutionary -- and I do think github is revolutionary, albeit for a niche of geeks -- should come out of such a development is testament of git's design.
Sure it's a hard package to master -- I haven't -- but whatever you want, and a lot more, is there if you need it. And no-one yet, to my knowledge, has complained that git killed their project.
Well said. When I talk to people at conferences and whatnot about GitHub, they're often surprised we run a core git stack with few modifications. Repositories are stored as plain old git repositories and we use git's normal command line interface for many types of operations.
It really is a testament to git's design (and I think maybe classically designed UNIX programs in general) that we've been able to do so much on the server with something designed mostly for local command line interaction.
People still talk about git's "lack of extensibility" (i.e., no library / you can't write extension programs in Python) but I've found that the "write programs that do one thing" model lends itself extremely well to all kinds of unplanned and novel uses.
I get the same impression from all the git-related submissions. It's like I'm being told that "this car is great. Just remember to jerk the door handle when you open it, give the window a nudge with your elbow before you open it, and the wipers will work extra well if you enable air-conditioning at the same time.
It makes it sound like default, basic git is either broken (merge/rebase) or very constrained for general purposes.
I think it also has to do with the fact that "productivity" tips are conflated with getting-it-right articles. You don't need to alias all commands for git to work, even though it might help your workflow - or not; YMMV.
I've spent a lot of time thinking through this problem. I agree Git is broken. So is Mercurial, Bazaar, subversion and CVS — they're just different flavors of broken (as in they each taste less broken to different groups of people).
Version control is inherently a difficult problem to conceptualize. Distributed version control is probably the biggest step forward VCS have ever seen — but it comes at a price of added complexity on top of a complex subject as is.
But then again that's why I don't focus on "making git better" — I try and focus on making collaboration and source control better. Stop trying to build aliases or tweaks to git's command line... and maybe try and build a great source control tool that just happens to use Git as it's storage engine.
Watch this video and you will become enlightened as to why this is the case:
[Linus Torvalds on Git] http://www.youtube.com/watch?v=4XpnKHJAok8
For a "git with good defaults", check out is easygit (eg). It's a Perl porcelain wrapper for git.
http://people.gnome.org/~newren/eg/
easygit uses real git commands, so you don't need to unlearn anything when graduating to git. It has safer defaults and extra sanity checks (like checking for unstaged changes when committing). The help messages are more verbose and use more consistent terminology than git's man pages. For example, easygit always uses the term "staged" instead of "index/staged/add/hard/soft/mixed/cached/HEAD/etc." And `eg revert` behaves the same as Perforce, SVN, and Mercurial revert.