GitHub API: "compare two commits" unclear

1
votes

Context

I'm making a tool which uses the GitHub API (Useful Forks). I'm currently trying to understand the behavior I'm seeing with the compare 2 commits api. I've gone through the following reading material:

  1. GitHub API compare 2 commits documentation
  2. StackOverflow question #1: GitHub API - how to compare 2 commits
  3. StackOverflow question #2: Github Comparison View for 2 branches is incorrect?

But I'm still puzzled...

Problem

Reproducible steps:

  1. Confirm that this parent repository exists: https://github.com/yellowstonegames/SquidLib/network/members
  2. Confirm that this is one of its forks: https://github.com/manderin87/SquidLib
  3. Confirm that GitHub acknowledges that it's both behind and ahead of the parent repo: commit counts
  4. Confirm that calling the GitHub API to compare the parent and the fork's master branch somehow doesn't seem to work: https://api.github.com/repos/yellowstonegames/SquidLib/compare/master...manderin87:master

The response is:

{
  "message": "No common ancestor between master and manderin87:master.",
  "documentation_url": "https://docs.github.com/rest/reference/repos#compare-two-commits"
}

I'm not sure I understand if this is the expected behavior or not. (And where could I find a list of all the possible error messages and what triggers them for that particular endpoint?)

Question

How am I supposed to obtain the numbers given in the screenshot above? (ahead and behind)

Extra question

I find it suspicious that all the forks for which this API call I'm making doesn't return an error have exactly 1379 commits behind the original repo. You can see that through my tool: https://useful-forks.github.io/?repository=yellowstonegames/SquidLib

confusing results

Once again, this possibly goes toward my lack of understanding of what this api call is supposed to be returning?

1
gitgithubgithub-api

1 Answers

0
votes

How many commits are there in the history of master for this specific repo ?

The elements you describe could be coherent with a bulk rewriting of the history of the original repo (a git filter-branch operation for example).

Check the sha1 for the first commit in the original repo and in one of its forks, for example.

Using local git commands : you can use git rev-list --count a..b (resp b..a) to see how many commits b is ahead (resp behind) of a.

a..b works even if a and b have no common history.

git rev-list a...b on the other hand searches for a merge base between a and b, and will fail if there isn't one.

I don't know exactly what API to use to match git rev-list a..b, perhaps "List commits" (referred to in the doc you linked) would allow it.