> -----Original Message----- > From: Florian Weimer <f...@deneb.enyo.de> > > * 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_me > > rged_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'm not sure and couldn't find a clear answer from a look in the docs.. But I believe it's using git for the rebase so might be able to do it with githooks? It does have some built in conflicts resolution methods but with some surprising limitations: --- The file, with conflict markers added, is not over 200 KB in size --- And also --- Note: GitLab resolves conflicts by creating a merge commit in the source branch that is not automatically merged into the target branch. This allows the merge commit to be reviewed and tested before the changes are merged, preventing unintended changes entering the target branch without review or breaking the build. --- So you probably don't want it to be aware of the conflict.. Cheers, Tamar
