Closed webbnh closed 10 months ago
why did GitHub re-integrate commits already on the branch? That's ... weird, and maybe a bit disturbing.
I think the blame (eh-hem) falls on Git. If I look at the history tree, the common ancestor between main
and b1.0
is
070b17080 Handle missing Opensearch indices (#3584)
which, on the b1.0
branch, is followed by
ff949f43b Correct Jenkins branchname value
and then by the same six commits which are on the main
branch...which makes sense, because that commit is the first on that we added to the b1.0
branch and then we merged the commits from main
later.
So, (I theorize) now that we're merging main
onto the b1.0
branch again, it starts at the branch point and lists all the commits from main
to be added, but, when the merge actually happens, Git determines that the first six commits are already present and skips adding them; thus, the net result is that there is only one commit different, which is the Jenkins branchname
value.
So, I don't really like it, but it seems to make sense, and it seems to produce the correct result. (And, really, we should not be rebasing the b1.0
branch and we should be merging main
into it, so, yeah, we're being forced to do the right thing, even if the process was kind of cumbersome.) My main concern was that I had to do a manual merge in the process (and that I botched it the first time!).
But, all's well that ends.
This PR brings the
b1.0
branch up to date with themain
branch. The only difference between the two is the contents ofjenkins/branch.name
.PRs #3592 through #3598 will be new to this branch; the commits for PR #3586 through #3591 are already on the
b1.0
branch, so I'm not sure why they are included in this PR.