Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [smarthome-dev] Merge strategy

Having used the rebase and merge on 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.


On 9 Oct 2016, at 21:23, Kai Kreuzer <kai@xxxxxxxxxxx> wrote:

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?


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.

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,
smarthome-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit

Back to the top