No nightly on 2018-12-07

[RalfJung]

$ rustup update
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: checking for self-updates

   stable-x86_64-unknown-linux-gnu unchanged - rustc 1.31.0 (abe02cefd 2018-12-04)
  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.32.0-nightly (14997d56a 2018-12-05)

As you can see, the latest nightly still has a commit dating from 2018-12-05, meaning it is the nightly created on 2018-12-06 (shortly after midnight). There was no nightly created today.

Cc @rust-lang/infra

[alexcrichton]

Dec  7 00:03:38 ip-10-202-181-185 release-nightly: Updating submodule src/tools/miri
Dec  7 00:03:38 ip-10-202-181-185 release-nightly: fatal: reference is not a tree: 61f20761d3124f5a1b1caee8aa15637cc7f92d8e
Dec  7 00:03:38 ip-10-202-181-185 release-nightly: Unable to checkout '61f20761d3124f5a1b1caee8aa15637cc7f92d8e' in submodule path 'src/tools/miri'
Dec  7 00:03:38 ip-10-202-181-185 release-nightly: failed to run: git submodule update --init --recursive src/tools/miri

@RalfJung or @oli-obk was miri force-pushed recently perhaps?

[RalfJung]

No, but I made a PR updating miri to a commit that's in a miri PR, not in miri master. Because GH adds PR commits to the target repo I thought that should work, and it did work locally and on CI.

I now made a branch in the miri repo containing that commit, I don't know if having it in a branch vs. a PR makes a difference though (I think it should not).

Is the release machine using an ancient version of git? Seems like the same problem that @jethrogb had (#56307 (comment)) with git 2.7 (which is almost 3 years old).

[o01eg]

Is the release machine using an ancient version of git? Seems like the same problem that @jethrogb had (#56307 (comment)) with git 2.7 (which is almost 3 years old).

I got same issue with git 2.19.

[jethrogb]

This should sort itself out then, now that the commit is available upstream, no? But yeah, it would be good if such things were caught in CI. I think it would be reasonable to configure git in the most conservative way w.r.t. finding commits.

[RalfJung]

I got same issue with git 2.19.

Now that is strange. I don't have this issue.

$ git --version
git version 2.19.2

How do you reproduce this?

[Mark-Simulacrum]

git on RCS is currently 2.7.4 so that might explain at least part of the problem. I've filed rust-lang/rust-central-station#119 to try and update the Ubuntu used for RCS...

[alexcrichton]

We got a nightly last night, so closing! I think this is otherwise diagnosed and being fixed