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.
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.
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.
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.
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.
[Linus Torvalds on Git] http://www.youtube.com/watch?v=4XpnKHJAok8
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.
All that hard work for nothing. Damn, another company listening to the needs of their users. What are they thinking...
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.
https://img.skitch.com/20110426-gjj8fcrdmayyinfgb57bgtgcns.j...
That's an interesting request though. This isn't the email I have configured in my ~/.gitconfig either.
