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(a)gmail.com>wrote;wrote:
On Wed, 06 Nov 2013 09:40:59 +0100, Antoine Musso
<hashar+wmf(a)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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l