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
