I believe it was introduced to cherry-pick upstream PRs, but that simply
doesn't work. Assume upstream is two PRs A and B ahead, and A has been
merged before B. Then trying to cherry-picking B by merging the state of
upstream's master after the merge-B commit won't do what we expect. In
particular, the merge result will *include A's changes* because A had
already been merged in upstream's master when B was merged.
(One could think that merging the PR branch of B instead works, but this
will yield the same result if B was rebased on master before it was
merged.)
The proper way to cherry-pick B is to create a PR that cherry-picks all
commits that had been included in B. This could be done automatically,
but the need to cherry-pick a PR is rare enough that we don't need tool
support for it. In fact, because we want to keep cherry-picking at a
minimum, there's a good chance that we'd anyway want to pick only a
subset of the commits in a upstream PR, and that would need manual work
anyway.
349a94b169