> Of course rebasing a green PR may lead to a red main branch in bad circumstances
At the moment the Platform CI rebuilds every open PR against current master on every master commit. That build is done with a merge commit of PR and master, so even the 1 in 1000 cases you are seeing probably goes away too. The above may change once there start being a lot of open PRs and the CI is forever rebuilding PRs. For example https://github.com/eclipse-platform/eclipse.platform.resources/pull/4 has been rebuilt 14 times https://ci.eclipse.org/platform/job/eclipse.platform.resources/job/PR-4/ even though there has only been a single commit on that PR. HTH in the decision making. Jonah ~~~ Jonah Graham Kichwa Coders www.kichwacoders.com On Thu, 31 Mar 2022 at 12:34, Michael Keppler <michael.kepp...@gmx.de> wrote: > Am 29.03.2022 um 21:38 schrieb Gayan Perera: > > > > It would be really good if we can enforce ff-merge only to avoid hard > > to trace history graphs. > > > That's one of the things that makes one-time-contributors abandon their > change after initial submission quite often, to my experience. They > can't do anything than rebasing, and rebasing again, and so on, every > time that a project committer submitted one of their own changes first. > And every time the hope on someone really merging the change goes down a > bit more. > > Just get used to rebasing as default merge strategy instead. That also > gives a linear history, doesn't require contributors to repeatedly do > work that doesn't create value and has in fact been already used on the > eclipse gerrit by some projects without any issues. > > Of course rebasing a green PR may lead to a red main branch in bad > circumstances, so chances of breaking the main branch are a bit higher > than with ff only. In our company we use rebase on merge and we see it > between 1 and 2 times per 10000 commits, that the target branch is > broken because of this (where "ff only" would have detected a broken > build). I would claim that there are _way_ more broken builds because of > other uncontrolled changes (some permission changed on some eclipse > server, an upgrade of some tool that everyone thought is unrelated, > ...), so that this tiny additional chance of a red main branch doesn't > really matter. But it improves the ability to just merge _everything_ > that has been reviewed and tested, instead of exactly 1 out of the same > set of changes, and then someone having to rebase and to wait 20 minutes > for building until the next 1 change can be merged. > > Ciao, Michael > > _______________________________________________ > platform-dev mailing list > platform-dev@eclipse.org > To unsubscribe from this list, visit > https://www.eclipse.org/mailman/listinfo/platform-dev >
_______________________________________________ platform-dev mailing list platform-dev@eclipse.org To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/platform-dev
