Rugged::Repository.merge_base complains when the merge base is a graft

[dgholz]

Hello, I have some CI jobs that try to avoid checking out unnecessary commits for merges. They call the GitHub API to see how many commits behind/ahead they are, compared to the base branch, and then fetch the base/merge branch with depth equal to number of commits they are behind/ahead + 1.

When one of the test tools calls Rugged::Repository.merge_base, if the merge base commit is a graft commit (from the shallow fetch), I get an error like:

Traceback (most recent call last):
	1: from show_merge_base.rb:9:in `<main>'
show_merge_base.rb:9:in `merge_base': object not found - no match for id (fab6d6845fe971f1bb15b793c5604ce7aeb0eaa2) (Rugged::OdbError)

where fab6d6845fe971f1bb15b793c5604ce7aeb0eaa2 is the parent of the grafted commit.

I see that git handles it fine :

$ git merge-base HEAD master
6e85c6c9868ba19e1b8c2f41890f02d37d9c8634

Increasing the shallow depth by one prevents the error, but I feel like merge_base shouldn't be looking for commits that aren't needed to calculate the merge base.

I created a repo to make it easier to reproduce the error, and included exact steps: https://github.com/dgholz/libgit2_merge_base

[Skipants]

I've had a similar thing happen to me on Gitlab CI. The weird thing is is that Gitlab has a default shallow fetch depth of 50 which I thought should more than cover the merge base. But when I checked the SHA that Rugged is calculating at the merge base it goes to a depth of 580:

> git rev-list HEAD ^30269071a898eae6ebbc20cc8c2bc579eefffb8c --count
> 580

The merge-base I get directly from git has the correct depth of 20:

> git merge-base --fork-point master
362ae5661143ddddb735d52f2b7a6a88a452595f
> git rev-list HEAD ^362ae5661143ddddb735d52f2b7a6a88a452595f --count
20

If your test tool takes in a commit SHA I've been overwriting it with $(git merge-base --fork-point master). In my case it's pronto: pronto run -c $(git merge-base --fork-point master)