When a PR is destined for master and release-xx.yy, it is a bit of a chore to rebase. But if it is based on git merge-base master release-xx.yy, it can be merged to both branches without any hassle. Furthermore, if many PRs do this, that “lattice meet” gets one everything in common between the branches, not just the point at which we made the release-xx.yy.
I…um…sneakily did this with 18.03 just myself. it worked quite well, except when there was a cherry-picked commit that I depended on but wasn’t part of the git merge-base history. In other words, it worked quite well but for network effects. What do you all think? is this something we can try for 18.09?
Assuming one doesn’t know about git-merge-base, would you be kind enough to provide a 1000 foot (304.8m) overview? Especially with related links, and a general use case example of its use with nixpkgs?
Got merge base finds the most recent ancestor of two commits. It traverses both sides of merges, so if you merge a PR into both branches, the most recent ancestor is “updated”
the GitHub UI will show you just the old context in the diff, etc. which may be confusing in some cases;
you will additionally have to check if there are no conflicts before choosing the base;
testing the PR will be more difficult, unless you’re OK to test it on an old version (IIRC Borg does a merge before building, but I’m not 100% certain).
On thing that one could do would be an actual branch which is merged into release-xx and unstable, rather than “virtual branch” whose tip is computed with git merge-base. That might help with the GitHub part, but make the ofborg part more complicated as the the PR’s target banch is just an intermediary.
I’m less worried about conflicts since, IIRC, most backports have no conflicts. Conversely, it’s already a lot of work if something changed significantly between the release and unstable.
The main issue I’m trying to solve, which I didn’t articulate in the OP, is that it’s much more difficult to very a commit was indeed backported with a cherry-pick than a merge.
Well, yes, computationally it’s difficult to do git log master..release-xx --grep hashThatInterestsMe (as we use cherry-pick -x), and there’s moreover uncertainty if the merge commit or individual commits were picked (i.e. for which hash to search). One reason I prefer to cherry-pick the merge commits directly is that it creates a mention in the PR.