Having used the rebase and merge on https://github.com/eclipse/smarthome/pull/2354 right now, I noticed one bad thing about it: The link to the PR is lost in the commit history. I very much liked to look at the commit history and have a clear link to the PRs from it - it is imho pretty useful for tracing discussions that let to certain commits.
I therefore would prefer to keep the squash and merge strategy - if there is a reason for separate commits, it should also be fine to do separate PRs. The only exception might be code formatting commits, but imho we should try to keep it to a minimum.
Regards, Kai
New Github features all the time⦠Yeah, I also noticed the new option (when merging 2280) and thought about using it. In cases like 2280 where the commits are clearly structured and make sense each on their own, I would agree that we should use it. In all other cases, we should imho stay with the squashing. So for me, I am ok to leave the decision to the committer who merges a PR. Shall we agree on this? Regards, Kai On 9 Oct 2016, at 11:01, Markus Rathgeb <maggu2810@xxxxxxxxx> wrote:
Hi guys,
there are now (for a while now) three merge options: * Create a merge commit * Squash and merge * Rebase and merge
IIRC the last one has not been available on our previous discussion.
Normally we are using "Squash and merge" now all the time.
If a developer splits its commits of a branch into separate commits it is sometimes useful (IMHO) to keep that commits separate. They could be all independent of the other but all be related to the same topic.
E.g. https://github.com/eclipse/smarthome/pull/2280 All the commits fixes the D-Bus transport bundle but every commit fixes different independent stuff.
Should we consider using "Rebase and merge" for PRs like this?
Best regards, Markus _______________________________________________ smarthome-dev mailing list smarthome-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/smarthome-dev
|