17

I forked a project on Github, made a small change and sent a pull request to the original maintainer, who has pulled it in. Now the last commit there is Merged pull request #11 from my_username/master.

This is the first time I'm doing this, so I'm not sure what the etiquette now is: I did a git pull upstream master and then git push origin master, and now the last commit on my own repository reads Merged pull request #11 from my_username/master which feels pretty weird to me. Is this the way people usually do it, is there anything I need to do to "clean up the history" or something?

Note: since this was a tiny documentation change, I hadn't created any branches, I just made the change in my master branch and sent the pull req. So there's no cleanup to be done in that part.

Sundar R
  • 272
  • 1
  • 9

1 Answers1

10

Yes, this is what people usually do, because it is what git does.

The merge tests often don't make sense. It is the result of the "fast forward" logic, i.e. merging does not create new commit if it is not necessary. Most of the time last commit on master says "merged master", because the developer merged master to their branch and pushed to merge, which didn't need any more merges. Nobody cares about merge commits in git anyway.

Jan Hudec
  • 18,250
  • 1
  • 39
  • 62
  • 5
    If you *do* care, however, you may find the `no-ff` option of `git merge` useful when merging to master. – Xion Aug 26 '13 at 10:08