Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.

share|improve this question

1 Answer 1

up vote 9 down vote accepted

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.

share|improve this answer
4  
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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.