Could we do an end run around to fix this? For example add a
Release-Notes: this text shows up in the release notes
field to the commit. Before release branching, some slightly-fancier variant of "git log | egrep '^Release-Notes:'" gets run to automatically populate the release notes with the appropriate information. Then we don't have to fiddle with the merge algorithm. --scott
On Wed, Nov 6, 2013 at 4:43 AM, Bartosz Dziewoński matma.rex@gmail.comwrote:
On Wed, 06 Nov 2013 09:40:59 +0100, Antoine Musso hashar+wmf@free.fr wrote:
We could surely add a feature in Zuul that would let us ignore conflicts
for some files. That should be possible by defining a merge driver using the "ours" strategy and then apply that driver in /.gitattributes for the RELEASE-NOTES* files.
You could probably use my driver for this (linked in earlier post, also [1]), which does some mostly meaningful checks to decide if the release notes are mergeable.
A side effect is that the gate-and-submit jobs would work properly but
Gerrit would end up refusing to submit the patchset because it cant merge it :-/
Yeah… JGit (which is what gerrit uses instead of git) does also supports merge drivers (or so says its documentation), it can't possibly be very hard to set one up – someone would just have to reimplement the algorithm in Java.
Or maybe we could have another bot to rebase using my driver before gate-and-submit runs. But personally I have no idea if/how it could be implemented; Antoine?
[1] https://github.com/MatmaRex/mediawikireleasenotes-driver
-- Matma Rex
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l