# Two ways to get an accepted patch into the master branch?

**URL:** <https://discourse.itk.org/t/two-ways-to-get-an-accepted-patch-into-the-master-branch/1456>\
**Category:** Community\
**Created:** [December 4, 2018, 6:46pm UTC](https://discourse.itk.org/t/two-ways-to-get-an-accepted-patch-into-the-master-branch/1456 "2018-12-04T18:46:12Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [December 4, 2018, 6:46pm UTC](https://discourse.itk.org/t/two-ways-to-get-an-accepted-patch-into-the-master-branch/1456/1 "2018-12-04T18:46:12Z")

</div>

Just noticed there’s a slight difference between the way @matt.mccormick and @hjmjohnson moved a commit from a pull request of mine into the master: [https://github.com/InsightSoftwareConsortium/ITK/commits/master](https://github.com/InsightSoftwareConsortium/ITK/commits/master)

With Matt’s approach, there appears a separate “Merge pull request” commit (“thewtex committed”), as well as my proposed commit (“N-Dekker committed”). With Hans, there appears only one commit, saying “N-Dekker authored and hjmjohnson committed”.

It seems to me that both approaches have their pro’s and cons. I like Matt’s approach _slightly_ better, as it clearly indicates the merge date. (Which might be quite different from the original date of the proposed commit). But others might say that Matt’s approach pollutes the log history 😮

No big deal, of course, just something I noticed. 🙂

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [December 4, 2018, 7:11pm UTC](https://discourse.itk.org/t/two-ways-to-get-an-accepted-patch-into-the-master-branch/1456/2 "2018-12-04T19:11:47Z")

</div>

A keen observation, @Niels_Dekker 🦅

To explain what is happening:

When a branch is created from the tip of `master` and merged in before other commits have been added to `master`, then no other commits are necessary. However, if other commits have been merged to `master` in the meantime, then Git creates an additional _merge commit_. Sometimes this commit will also contain merge conflict resolution content that was automated or manually resolved.

---

<div class="post-metadata">

**Author:** ![Niels\_Dekker](https://discourse.itk.org/letter_avatar_proxy/v4/letter/n/9d8465/32.png) [@Niels\_Dekker](https://discourse.itk.org/u/Niels_Dekker)\
**Post date:** [December 4, 2018, 7:24pm UTC](https://discourse.itk.org/t/two-ways-to-get-an-accepted-patch-into-the-master-branch/1456/3 "2018-12-04T19:24:56Z")

</div>

> [@matt.mccormick](#):
>
> When a branch is created from the tip of `master` and merged in before other commits have been added to `master` , then no other commits are necessary. However, if other commits have been merged to `master` in the meantime, then Git creates an additional _merge commit_ . Sometimes this commit will also contain merge conflict resolution content that was automated or manually resolved.

Thanks for your explanation, Matt. But if it’s not a disagreement between your and Hans’ approach, I guess my observation wasn’t _that_ keen 🙃

Do I understand correctly that if I would actually _want_ to have just a single commit for my pull request, I should `fetch upstream` and `rebase` my branch, just before the `review-push`?

---

<div class="post-metadata">

**Author:** ![matt.mccormick](https://discourse.itk.org/user_avatar/discourse.itk.org/matt.mccormick/32/7_2.png) [@matt.mccormick](https://discourse.itk.org/u/matt.mccormick)\
**Post date:** [December 4, 2018, 7:28pm UTC](https://discourse.itk.org/t/two-ways-to-get-an-accepted-patch-into-the-master-branch/1456/4 "2018-12-04T19:28:53Z")

</div>

> [@Niels\_Dekker](#):
>
> Do I understand correctly that if I would actually _want_ to have just a single commit for my pull request, I should `fetch upstream` and `rebase` my branch, just before the `review-push` ?

Right. 👍