Le 13/12/2011 10:33, Nathan Broadbent a écrit :
You can't do a cherry pick or rebase through the front-end. I think adding this 'merge pull request' commit is a good idea, since it shows more information about where the commit came from.
OK. So I assume its best practice also on github to do so?
Yes, this is a best practice. It's also a best practice to add a 'merge' commit when merging in a feature branch, so that the branch's diversion is retained.
Github's network graph [1] and gitk [2] are great tools for viewing this history, and you shouldn't worry too much about making the history as 'linear' as possible.
While I agree that when there are more than one commit in a branch it shouldn't be rebased to keep the branch history, I don't agree when it's a single commit like [1] or even [2].
When it's a single commit, I think it only adds junk to the history, making it less readable. And I don't see what we gain with the merge message in such situations:
1) we don't care it was a GitHub pull request and not a format-patch; 2) the branch name shouldn't be required, the commit should be enough; 3) the patch contains authoring information anyway; 4) etc.
So IMHO it's better for single-commit patches (which should generally be quite small BTW) NOT to have the merge commit.
Regards, Colomban
[1] https://github.com/geany/geany/commit/903e69b388b935cfb135312a3a76b04608133a... [2] https://github.com/geany/geany/commit/8f280ed884721a0a1c75462e428b9bcffb3ac5...