search

distributed-system-analysis / pbench

A benchmarking and performance analysis framework
http://distributed-system-analysis.github.io/pbench/
GNU General Public License v3.0
186 stars 108 forks source link

Update b1.0 #3601

Closed webbnh closed 8 months ago

webbnh commented 8 months ago

This PR brings the b1.0 branch up to date with the main branch. The only difference between the two is the contents of jenkins/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.

webbnh commented 8 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.