On Thu, 23 Apr 2020 at 06:49, Florian Weimer wrote: > > * Tamar Christina: > > > A bit late to the party, but this really doesn't work that well > > because until recent version of gitlab there was no fairness > > guarantee. another patch could be approved after mine (with hours > > in between because of CI) and yet still get merged first causing my > > own patch to no longer apply, you'd rebase and roll the dice again. > > To fix this they added merge trains > > https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/ > > > > but trains for GCC Will likely be very short because of Changelog > > conflicts. So I don't think an automated merge workflow would work > > for projects where every single commit changes the same files. > > I had not thought about that. > > Does Gitlab support pluggable merge helpers? The gnulib changelog > auto-merger did a great job when we were still writing changelogs for > glibc.
I've been having problems with it recently, e.g. https://gcc.gnu.org/g:e76100ced607218a3bf had to fix a changelog, because https://gcc.gnu.org/g:d76925e46fad09fc9be67 put my changelog entry in the wrong place in gcc/testsuite/Changelog, as a result of a rebase using merge-changelog. Maybe we should follow glibc and get rid of ChangeLog files before trying to use automated CI and Git workflows.
