7 ms·

The Merge Button

254 points by tmm1 15y ago

yuvadam 15y ago
Amazing! This feature was long overdue.
timdorr 15y ago
And from 4 days ago: http://ejohn.org/blog/pulley/ http://ejohn.org/blog/pulley/ All that hard work for nothing. Damn, another company listening to the needs of their users. What are they thinking...
- technoweenie 15y ago
  The merge button doesn't squash commits or anything. Pulley looks like a nice way to use a custom workflow with Pull Requests.
neworbit 15y ago
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!
macrael 15y ago
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.
- cpeterso 15y ago
  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/ 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.
- kmfrk 15y ago
  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.
  - JonnieCache 15y ago
    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 http://www.youtube.com/watch?v=4XpnKHJAok8
  - kneath 15y ago
    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.
- auxbuss 15y ago
  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.
  - rtomayko 15y ago
    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.
flexterra 15y ago
I really like how Github is always pushing new features all the time.
jvoorhis 15y ago
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.
- bkudria 15y ago
  I look forward to the day GitHub implements a CI service.
- eru 15y ago
  We have a bot at work that does exactly that.
- dblock 15y ago
  +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 :(
pilif 15y ago
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.
- rtomayko 15y ago
  It's not. The primary profile email is used currently: https://img.skitch.com/20110426-gjj8fcrdmayyinfgb57bgtgcns.jpg 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.

254 points by tmm1 15y ago

Amazing! This feature was long overdue.

And from 4 days ago: http://ejohn.org/blog/pulley/ http://ejohn.org/blog/pulley/ All that hard work for nothing. Damn, another company listening to the needs of their users. What are they thinking...

technoweenie 15y ago
The merge button doesn't squash commits or anything. Pulley looks like a nice way to use a custom workflow with Pull Requests.

neworbit 15y ago

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!

macrael 15y ago

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.

cpeterso 15y ago
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/ 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.
kmfrk 15y ago
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.
- JonnieCache 15y ago
  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 http://www.youtube.com/watch?v=4XpnKHJAok8
- kneath 15y ago
  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.
auxbuss 15y ago
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.
- rtomayko 15y ago
  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.

flexterra 15y ago

I really like how Github is always pushing new features all the time.

jvoorhis 15y ago

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.

bkudria 15y ago
I look forward to the day GitHub implements a CI service.
eru 15y ago
We have a bot at work that does exactly that.
dblock 15y ago
+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 :(

pilif 15y ago

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.

rtomayko 15y ago
It's not. The primary profile email is used currently: https://img.skitch.com/20110426-gjj8fcrdmayyinfgb57bgtgcns.jpg 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.