Thanks. Are you sure this is a good idea? Because it means that if non-Omicron workspaces depend on a different revision of qorb it might become hard to reconcile that with Omicron -- you'll have two copies of qorb floating around. Using main avoids these problems.

Pinning qorb in Cargo.lock might be enough, maybe?

I thought that if I specified "use the master branch" in cargo.toml, and then manually tried to update cargo.lock, that change to the lockfile would get overwritten the next time someone tries to build?

My concern is that if I commit a breaking change to qorb it'll immediately break omicron's build

I could also just start publishing / using published versions of qorb?

I could also just start publishing / using published versions of qorb?

Hrm, okay, can't do this without updating diesel-dtrace, where we also seem to be using the main branch

I published a new revision of diesel-dtrace and qorb, and I'm using them here now.

I thought that if I specified "use the master branch" in cargo.toml, and then manually tried to update cargo.lock, that change to the lockfile would get overwritten the next time someone tries to build?

Only if something causes the update to happen -- in general, the git repo being updated by itself won't cause a local update. In your case I guess you bumped another dependency which caused it?

My concern is that if I commit a breaking change to qorb it'll immediately break omicron's build

No, this won't happen automatically.