When a PR is destined for
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
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?
it is a bit of a chore to rebase
Because of the massive list of changes to remove? How about cherry-picking? I’m not sure I understand the problem.
Yes, sorry, I mean interatively
git cherry-pick -xing is a chore. If we could actually rebase, it wouldn’t be so bad.
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?
Official docs: Git - git-merge-base Documentation
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”
I fear it won’t be worth it as a common workflow:
- 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.
Python is apparently using issue-tags to instruct a bot to do the backporting: https://github.com/python/cpython/pull/6118#issuecomment-419351104