

GitHub Merge Button - What Were they Thinking? - walkon
http://ayende.com/Blog/archive/2011/05/06/what-where-they-thinking-the-github-merge-button-is-stupid.aspx

======
tsigo
That button is a convenience for the "Hey I fixed a typo in your README"-type
changes. Of course for a major feature addition you'll still want to do it the
old way, which is obviously still possible.

------
jarin
They were probably thinking "Let's make our product more convenient and easier
to use."

------
martian
I used this button 3 times today and am happier for it.

------
dlsspy
I made these same complaints in their blog post comments when it came out.
They made it harder to test code without first publishing it (i.e. welcome to
CVS) and in the trivial cases where someone submits a spelling fix to your
docs and you're sure it won't break anything, it now introduces two commits to
do that, the second (the one showing at the top) providing potentially much
less information.

I think it's good that they're making things easier, but fork queue (which
seems mostly abandoned these days) seemed to solve these problems better.
Understanding of course that none of cherry-picking, forced recursive merging
or fast-forward merges is always right for everyone.

------
kenneth_reitz
It thoroughly depends on the use case. If someone's submitting a documentation
change, I have no problem at all merging in with the merge button. It's
perfect.

I think the button should be used sparingly, but I'm extremely happy that it's
there.

Small changes to a non-crucial project shouldn't be that big of a deal. Bigger
projects typically have a more proper master/develop branch structure, and
that unstable branch is there for a reason.

Also, GitHub is often used privately by trusted teams, so merging a repo from
a colleague or coworker without testing first could be proper in many
situations.

------
ballard
Checkout pulley

<https://github.com/jeresig/pulley/blob/master/pulley.js>

