Error cloning empty repos

[w3s7y]

If during discovery of repos we find some that are completely empty, when git.py comes to clone them we see:

AssertionError: Remote 'origin' has no refspec set.

Line 93 in switch_branch_then_pull of git.py

Which is thrown all the way up the stack (uncaught exception) and causes mass-driver run to exit non-zero.

Possible solutions

• During discovery phase (potentially in a plugged-in source) we omit empty repos from the run entirely
  • Would need to perform an additional API request per repo to determine if repo has 0 commits. Could get expensive...
• The pull code in git.py is wrapped to catch the error and log it, then remove the repo from processing

[w3s7y]

Played around with option 1 (using a custom gitlab source) and it is possible:

• In the discover function, once all the repos from the initial search are retrieved from the API
• Include a second API call to the commits API endpoint and len() the returned array
• if len() == 0: continue (Don't add the repo to the IndexedRepos the function returns)

It is hard on the gitlab API though, discovery turns from a ~10 API call job into a ~1010 API call job!

[OverkillGuy]

That's a good spot, though I was thinking about it in the past, let me tell you the reasoning.

I can't remember if this already made it to the main branch's code or if it's part of the mega-refactor that I never merged, but:

Discovery, Clone, Migration (aka Patch), and Scan are all "Activities", which need to happen in a specific order, which I call the Phases.
A specific repo goes through "Phases" of Activity: Discovery -> Clone -> Migration/Scan (same phase, as they both just need Clone phase completion).

The intent was to track all these activities' state, to say "This repo is currently at Phase X", and each Activity can have a status, from not done, to in progress, to done or even ERROR.

So the thing you're describing sounds like a Clone Error, where the Discovery was OK, but the Clone activity errored in irrecoverable way, and we may want to attach that details of what the failure was.

Short term, I need to catch that error to avoid a fall-through of exception.

Long term, I need to finalize that refactor branch that's been bugging me forever.
The sooner I land these big refactors (and fix associated bugs that I was tracking internally) the sooner I can upgrade this project to uv by upgrading the repo template, which closes the two big issues I have right now.