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.
It's a nice feature. I had a chance to use it today, and it worked beautifully. Its biggest downside is that you don't have an opportunity to run tests without first pulling the changes into your working copy, so I don't see it coming into play very often in my workflow.
+1 i was just thinking the same - we use github to do code reviews, so now merge help is gone I have to use my head to remember what to type to make the merge :(
This is an excellent idea and I look forward to actually using it. Thanks guys for making the world of distributed development and open source a better "place" to be!
I haven't tried it yet and trying it out would be quite a lot of work (set up a test repo, fork it, send pull request, merge), so I'm asking here first in the hope that somebody has already tried it:
is it possible to select the email address you want to make the merge commit as? My main email address I'm registered with github isn't the address I would want to make merge commits as.
All that hard work for nothing. Damn, another company listening to the needs of their users. What are they thinking...