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/903e69b388b935cfb135312a3a76b04608133a4e [2] https://github.com/geany/geany/commit/8f280ed884721a0a1c75462e428b9bcffb3ac527 _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel