Ayende @ Rahien

Hi!
My name is Oren Eini
Founder of Hibernating Rhinos LTD and RavenDB.
You can reach me by phone or email:

ayende@ayende.com

+972 52-548-6969

, @ Q c

Posts: 5,968 | Comments: 44,484

filter by tags archive

What where they THINKING? The github merge button is STUPID


I just love git pull requests, but the new behavior from GitHub is beyond moronic. Take a look at a typical pull request:

image

The problem is that clicking on this button would actually merge the changes to the public repository. I don’t know about you, but there are very few cases where this is what I want to do.

In 99.9999% of the cases, I want to merge this locally to see what the bloody changes are, run some tests, maybe modify the changes before I am taking them.  In this case, this particular pull request contains a failing test. I never want to commit that to the public repo automatically.

What is worse is that I now need to manually construct the pull command in the command line, whereas GitHub previously offered the option to generate that for me, which I liked much more.


Comments

tobi

Looks like somebody not using their own product.

Ayende Rahien

Tobi,

Actually, it is likely that they do.

But they are working within a trusted team, most probably, not within an open source community where you need to verify those changes.

fampinheiro

I can sugest in the admin of your repository that you define a new branch as the default branch. I think (untested, not at home) that you will merge the pull with that new branch.

This is a workaround not a solution. Just an ideia.

Masklinn

The merge button is pretty nice for merging stuff which doesn't really break, such as documentation fixes or typos.

It's definitely a bad idea for code changes, and a shame they removed the command-line help if the pull request can be automatically merged.

Simon

Ditch git and join the mercurial revolution :P

Steve

A tonne of people were asking for this and were incredibly excited when it was announced. So are they all morons too?

Christian Schlichtherle

I wonder what all the git fuzz is about. Since I've changed from CVS and SVN to Mercurial, I've never looked back.

Rik
Rik

@Christian git's just like hg - nothing sticks out as being particularly different AFAICT. I use hg because it works better on Windows which is where I do most work these days.

Jimmy Bogard

Agreed. I wouldn't care if they also hadn't taken away the auto-generated version. It now takes a lot of clicks to even get to the other person's repo they're wanting me to pull from.

Rob Ashton

Git vs Hg blah blah blah, come on people - do something more constructive with your time.

This is actually an annoyance, I also just want to copy the git instructions for merging in people's changes, and having the helpful messages removed is a step in a bad direction #nerdrage

Tim Clem

The old instructions for doing a local merge are still available from that same page. Just click the little i on the left hand side.

I agree that the majority of the time it would be foolish to blindly click the merge button. However, just knowing that changes will merge cleanly is very helpful to me. It also works really well for those 'I found a spelling mistake in your documentation or readme' patches.

Rob Ashton

Ooh, I hadn't seen that - rejoice as my nerd rage subsides

John Bender

I help manage pull requests for a large opensource project on Github and in short experience the "merge button" is nice for typos, documentation updates, and style compliance changes.

Dmytrii Nagirniak

Ayende,

I think I haven't read the help topic on Pull Requests (Merging Pull Requests section): http://help.github.com/pull-requests/

This is what you can do:

$ git remote add kneath git://github.com/kneath/jobs.git $ git fetch kneath $ git merge kneath/error-page $ git push origin master

Comment preview

Comments have been closed on this topic.

FUTURE POSTS

  1. Pointer arithmetic and dynamic HTML generation FTW–at 2 AM - 6 hours from now

There are posts all the way to Jul 28, 2015

RECENT SERIES

  1. Career planning (6):
    24 Jul 2015 - The immortal choices aren't
  2. Production postmortem (4):
    23 Jul 2015 - The case of the native memory leak
  3. API Design (7):
    20 Jul 2015 - We’ll let the users sort it out
  4. What is new in RavenDB 3.5 (3):
    15 Jul 2015 - Exploring data in the dark
  5. The RavenDB Comic Strip (3):
    28 May 2015 - Part III – High availability & sleeping soundly
View all series

Syndication

Main feed Feed Stats
Comments feed   Comments Feed Stats