cargo-crev: Can't commit or pull reviews: UnbornBranch

After cargo crev review foo I get:

Error: Could not not automatically commit caused by: reference ‘refs/heads/master’ not found; class=Reference (4); code=UnbornBranch (-9)

There are two problems here:

  1. There is a not-completely-initialized repo somewhere. It may be my fault, as I’ve tried earlier version of cargo-crev and didn’t fully follow instructions.

  2. The error doesn’t show path to the repo, so I don’t know where it is, and I can’t fix it.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 17 (6 by maintainers)

Most upvoted comments

BTW, instead of instructing users to create a new repo from scratch, you could suggest using forking a template, such as:

https://github.com/dpc/crev-proofs/fork

(of course maybe not this particular url).

The fork UI gives a properly-named, initialized repo, in 1 click.

@kornelski The forking idea has a great side-benefit: we get a list of people who clicked the button! https://github.com/crev-dev/crev-proofs/network/members

I moved to github organization, created a template repo and updated documentation to use one-click forking. Additional benefit - you can can get a list of forks.

The most likely way to hit this is when skimming the instructions at: https://github.com/dpc/crev/blob/master/cargo-crev/src/doc/getting_started.md#creating-a-crevid and overlooking:

Note: cargo-crev requires the master branch to already exist, so the repository you have created has to contains at least one existing commit.

Github is happy to create an uninitalized/commitless repository through https://github.com/new if you don’t select any of these options (and why would you?):

  • Initialize this repository with a README
  • Add .gitignore
  • Add a license

Then, since cargo crev new id doesn’t appear to do sanity checking to catch this, you end up in this state when you try to start using cargo crev trust. Manually creating a commit, deleting %APPDATA%\crev, and rerunning cargo crev new id fixes the issue.

I looked more into it, and I’m not sure if this is worth handling. I mean - this repo did not have HEAD set so technically was in invalid state. I don’t think it’s worth complicating things, just to try to recover from states that should not be there in the first place. If crev left it in the incorrect state - that’s a bug to fix.

@kornelski $HOME/Library/Application Support/? We’re using https://docs.rs/app_dirs/1.2.1/app_dirs/