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.


Geany-devel mailing list

Reply via email to