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....@gmail.com>wrote: > On Wed, 06 Nov 2013 09:40:59 +0100, Antoine Musso <hashar+...@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 > -- (http://cscott.net) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
