Bitbucket PR importer: failing if source commit has only closed descendent heads
Seen again with the PyPy import tests:
Bitbucket PR importer for pypy-2020-01-16/pypy Import failed for PR iid 406, error object not found - no match for id (f281ebb3c005de20b5ca4bd269ae470b7e9b681e), trace: /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/git/repository.rb:2587:in `merge_base'
but it looks like everything was fine until we called create()
, and then something within creation does not find a commit (probably a Git one).
There are six of these among the 644 PRs for PyPy, did investigate some. In all cases, the reason is that the source changeset is on a branch that's later been closed, and hasn't itself been merged. In that case, Mercurial has produced a Git commit, and is able to give us the Git sha, but the branch head has never been pushed to Git or has been pruned, hence is unreachable. This is correlated with pull requests from inner branches.
We could let closed heads go through to Git in the course of importing the changesets (we do have options for that), and prune them afterwards and issue a final prune after the import is fully done. Or we could put special refs on them, or…
But that's the kind of problem we won't have once on HGitaly, and it feels good enough and much simpler to
- check before calling
create()
if the Git changeset is known - if it isn't, create the MR with an empty set of commits, recalling the original Mercurial changeset hash in the description.
With the original Mercurial hash, someone who would want to restart something or would just be curious could still read the changesets from the command line. In the meanwhile, the discussion wouldn't be lost.