2

When doing open source development it's normal to track against the upstream for a period of time while doing any changes on a topic branch. One of the things I have noticed when bringing the upstream back is that a merge commit is created. If I then create a pull request this merge commit ends up as part of the PR.

My question is, is there any harm in this? I have read that some people feel they are useless but I like the fact that they act as a timestamp against when I last synced with the upstream. Is there an accepted practice for tracking the upstream and introducing merge commits.

McDonnellDean
  • 1,097
  • 2
  • 7
  • 23

1 Answers1

1

when bringing the upstream back is that a merge commit is created.

That is why it is preferable to:

  • git rebase master (rebase your branch on top of the updated remote tracking branch)
  • git push -f (force pushing your branch to your GitHub fork: the existing PR will be updated accordingly)

That works well if:

  • your PR is done in its own branch
  • nobody else is actively using your branch
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • While I can understand the above from the point of view of removing the extra commit, I'm still not sure I see the point of removing it other than some desire to manicure the commit stream. Perhaps you could elaborate on why this is necessary? – McDonnellDean Nov 06 '14 at 22:10
  • 1
    @McDonnellDean yes: http://stackoverflow.com/a/23285782/6309 and http://stackoverflow.com/a/14681796/6309. PR in GitHub are made to be forced push: they will be updated for you. The idea is to keep your PR in its own branch, always rebased on top the updated remote tracking branch, in order to make sure the final merge (done in the original repo) will be a trivial one. – VonC Nov 06 '14 at 22:14