Merge Pull Request Considered Harmful

I really do not see the problem with the rails commit history. Having those merge messages that point back to a pull request leaves lots of documentation about what was done and why it was done. I really do not know why people are so particular about their git log either. It shows an accurate history of the repo, not a revised cleaned up history.<p>However being able to edit pull request before merging was a good thing to learn. However I think in the long run I would want to learn it with plain old git rather than tack on another tool to my workflow.

Is this exactly situation that <a href="https://help.github.com/articles/checking-out-pull-requests-locally" rel="nofollow">https:&#x2F;&#x2F;help.github.com&#x2F;articles&#x2F;checking-out-pull-requests-...</a> documents?<p>So basically:<p><pre><code> git fetch origin pull&#x2F;ID&#x2F;head:BRANCHNAME git checkout BRANCHNAME </code></pre> And now you can edit that pull request and&#x2F;or make new pull request based on the previous one. Or just simply merge in master.

Hm... this seems like a very complicated way of saying that github should have a way to merge pull requests into a new branch.<p>...but it doesn&#x27;t so you have to:<p><pre><code> - checkout a local copy - add a remote to the PR - checkout a new branch - merge the PR into your local branch - fix code, merge to master </code></pre> Which is entirely true; it <i>is</i> annoying.<p>The simple solution, though, is to require pull requests to come in a feature branch, and flat out reject any that target master. <i>&#x2F;shrug</i>

Torvalds himself doesn&#x27;t like GitHub&#x27;s pull request workflow for several reasons and doesn&#x27;t accept pull requests on GH for the Linux kernel, see [1].<p>[1]: <a href="https://github.com/torvalds/linux/pull/17#issuecomment-5654674" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;torvalds&#x2F;linux&#x2F;pull&#x2F;17#issuecomment-56546...</a>

You know, when I started reading this I thought that I would disagree with you and write a grumpy comment to that effect. (&quot;Considered Harmful&quot; usually makes me grumpy.) However, you convinced me otherwise. Congratulations on a good &quot;Considered Harmful&quot; piece!<p>Here&#x27;s another example: I recently made a PR to a project to fix a broken URL. I changed a wrong file and forgot about the PR. The maintainer had to close the PR, make the change himself, and explain why&#x2F;what he did. This whole process would&#x27;ve been a lot simpler if Github allowed people to merge to another branch.

I just tried this on an open pull request we had. Pretty ok experience. For some reason though, there where a merge conflict when running the &quot;hub am -3 &lt;url&gt;&quot; command. In my case was easy to fix, but Github reported the PR to be mergeable, so maybe Github uses a different merge strategy for PR&#x27;s than &quot;hub am&quot; out of the box?

Just a note to people who want to try this: According to the post you should use the command &quot;git am -3 &lt;url&gt;&quot;, this seems to be a typo and should be: &quot;hub am -3 &lt;url&gt;&quot;

I&#x27;m not sure how I feel about someone writing something and making me the author. I guess attribution makes sense in the form of paraphrasing. But I tend to think of commits as literal quotations.

I&#x27;ve always just pulled in the contributor&#x27;s branch, made additional commits to fix things up, and squashed all the commits before pushing up to GitHub. Not very difficult

Interesting problem for committers. Since Github made the hub tool, maybe they could make this person&#x27;s flow better right from the web UI somehow.

What works best for me is to use a combination of the Pull Request button and to manually merge or rebase changes when necessary.<p>I used to strictly stay away from the Pull Request button, because it made my history &quot;messy&quot;. Now I care less about that and more about the convenience (when it&#x27;s appropriate).

I wish github would either detect when a branch is merged back into master and automatically close the PR, or allow for some more complex merge operation. Squash merge would be particularly helpful.

You should be able to update your fork to be the same as upstream, with one click on your fork.

&quot;And as a hypothetical story-telling construct I created in my mind, Jane agrees 100%!&quot;<p>That&#x27;s a very strange way to end an article. Could have just stopped before adding that last line.

Using the term &#x27;considered harmful&#x27; in a blog post title considered harmful.

I love the approach but hub seems to be Mac only :(

&quot;If the contribution is a single commit, I’ll do a git commit --amend and just smoosh my changes right into the original commit.&quot;<p>that is right, editing history is the way to go, or is it? :)

Considered Harmful blog posts Considered Harmful

harmful?