MediaWiki extensions often follow a 'release branch' strategy of maintaining compatibility with MediaWiki core. This means that there's a Git branch in an extension that matches each core version. The idea is that development happens on the master branch, and every six months a release branch such as REL1_44 is created (based on master). Then, the only additional commits that happen on the release branch are for security or compatibility purposes, and are either applied directly or are cherry-picked from master.
I find two aspects of this a little bit annoying: Firstly, the speed of development of an extension is often much higher than that of core (as it should be; core shouldn't be a thing that's changing all that much). And secondly, it's not hard to introduce incompatibilities into the master branch of an extension. The latter seems to happen a bit, but is most annoying when a change adds some incompatibility, and then a subsequent change fixes it, but the normal way to backport these doesn't work because you have to add them separately and CI fails.
The trick is to add them as a merge commit. (Or at least, that's what I reckon… it doesn't seem to be a very popular approach, so maybe this is all Bad Advice.) It goes something like the following, assuming master has a few commits that are needed on REL1_44.
# First make sure everything's up to date, and switch to a new branch based on the release branch:
git remote update
git checkout -b update1-44 gerrit/REL1_44
# Then create a merge commit with everything new from master:
git merge --no-ff gerrit/master
# Then upload the change for review, targeting the release branch:
git review REL1_44
My main RSS news feed: https://samwilson.id.au/news.rss
(or Wikimedia.rss, Fremantle.rss, OpenStreetMap.rss, etc. for topic feeds).
Email me at sam or leave a comment below…
samwilson.id.au