Skip to content

updateref package does not assert that refs are locked

The updateref package uses explicit transactional semantics with git-update-ref(1) such that we can be sure that no refs will be updated without us explicitly committing. Furthermore, we use it in some places to make sure that refs cannot be concurrently updated anymore by any other process via the "prepare" verb.

While the first usecase works alright, the latter doesn't: we do not listen for the status returned by git-update-ref(1), which would typically print something like "prepare: ok\n" to tell us that we have indeed locked refs successfully. So this step may fail without us knowing because of concurrent modifications, which makes this whole exercise kind of moot.

Fixing this would in theory be easy, but pratically it's not because Git does not flush out status updates and thus keeps them buffered. As a result, we'd deadlock waiting for its status update. This requires upstreaming a patch.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information