merge_base: revspec 'master' not found (Rugged::ReferenceError)

[salujabhavesh]

On running command :-

1. pronto run: (error:- /home/rails/.rvm/gems/ruby-2.4.10/gems/pronto-0.10.0/lib/pronto/git/repository.rb:87:in `merge_base': revspec 'master' not found (Rugged::ReferenceError)

2. bundle exec pronto run -c origin/master -f github_status -f github_pr_review --exit-code
   Getting error :- https://docs.github.com/rest/reference/pulls#list-pull-requests (Octokit::NotFound) + Faraday

Ruby Version :- 2.4.10
Rails Version :- 4.2.11
Linux version :- 16.04

[gilesbowkett]

I've seen this with Rugged in other contexts when the repo had main but not master, and I'm seeing it now for the same reason with Pronto. that makes it intuitive that main vs master would be the problem. but it seems like a really out-of-date problem, so I have doubts.

[gilesbowkett]

indeed, the main vs master aspect of this bug was first reported in 2016.

#191

per that page, using pronto run -c $(git name-rev --name-only HEAD) or pronto run -c main seems to fix it.

[gilesbowkett]

@ashkulz hi, #460 did not change this issue. the issue remains. I installed 0.11.3 and verified this.

the issue is that Pronto assumes you will be looking at master and you have to explicitly specify any other branch name (for instance main). #460 just added documentation for GitLab, but this issue is not limited to GitLab. it might not even be related to GitLab.

[ashkulz]

@gilesbowkett while the Usage does clearly state that the default branch is master, I do agree that adding an example about main (in case you've switched over to that as the default branch) would be very helpful.

While it's possible to detect what the default branch is, I'm not sure we want to do that as it's quite slow and I don't want to do that on every pronto run. Caching it is also not a good idea, as then what happens if you change it from the repo end -- it'd be expected to pick up the change.

So yeah, I'm leaning towards keeping the current behavior and document the non-master scenario as the first example. What do you think?

[gilesbowkett]

sure, that sounds good. personally I'd prefer making main the default. It's been the default for new repos on GitHub since 2020. but there are tons of legacy repos still using master. and either way, documenting the default in the README, along with the -c main fix, would be a nice improvement.

[ashkulz]

@gilesbowkett would it be possible for you to make a PR for this?

[gilesbowkett]

sure, I'll give it a shot