Count the beta prerelease number just from master

[cuviper]

We were computing a merge-base between the remote beta and master
branches, but this was giving incorrect answers for the first beta if
the remote hadn't been pushed yet. For instance, 1.45.0-beta.3359
corresponds to the number of merges since the 1.44 beta, but we really
want just .1 for the sole 1.45 beta promotion merge.

We don't really need to query the remote beta at all -- master..HEAD
suffices if we assume that we're on the intended beta branch already.

[rust-highfive]

r? @Mark-Simulacrum

(rust_highfive has picked a reviewer for you, use r? to override)

[cuviper]

FWIW, in my first draft I had a snippet like this:

        // We used to run `git ls-remote origin master`, but you still need that commit locally to
        // do things like `merge-base` or `rev-list`, so we might as well fetch it.
        run(Command::new("git").arg("fetch").arg("origin").arg("master").current_dir(&self.src));

... and then listed from FETCH_HEAD..HEAD. I can add that back if desired, but we don't really need a most-current master, just at least as recent as this beta was branched.

In fact, I think the old code that used ls-remote had a race in this regard, if something happened to merge into master after the local repo had last cloned/updated -- you could get a master commit that doesn't exist locally, and then merge-base would fail.

[Mark-Simulacrum]

Yes, this seems reasonable. I admit that I can't entirely follow the reasoning -- likely would need to sketch some commit trees out or so -- but I think that's not necessary, if it doesn't work that's not going to break anything I suspect anyway.

I thought about getting this into the current beta (backporting it) but I guess there's not that much point so I'm going to not do that.

@bors r+

[bors]

📌 Commit 37a24b3 has been approved by Mark-Simulacrum