getRef method bug

[hipporello]

Describe the bug
gitRef method uses wrong api end point. It causes a deserialization problem. It should use git/ref/%d instead of git/ref/%s.

[bitwiseman]

@hipporello
Which class's getRef() method? Please provide more details.

[hipporello]

Hi,

It is GHRepository class and the method signature is:

public GHRef getRef(String refName) throws IOException {

[bitwiseman]

@hipporello
Why should it use git/ref/%d?
Please provide and example where git/ref/%s does not work correctly.

[hipporello]

Hi,

You are using git/refs/%s currently for getRef method of GHRepository. This brings all matching references instead of a single ref value which I expect getRef should return. Instead of git/refs/%s, you should use git/ref/%s. This will bring exactly specified reference.

[bitwiseman]

So, the problem isn't %s but rather refs vs ref? I see.

I agree with your point and that this is bug. I'm somewhat concerned that fixing this might cause a significant behavior change.

[bitwiseman]

Having looked a bit more into this, the library has a getRefs() and a listRefs() methods (which as expected call into the git/refs endpoint). If someone expected something other than exactly one GHRef they would use those methods. So, at first glance it seems like this will produce some kind of change in behavior, but it is probably a good change to make.

Inputs

Let's say we have the following input ref path specifiers:

• heads/gh-pages
• heads/gh
• headz

Questions

• What is currently returned from GitHub API git/ref vs. git/refs for each input?
• What behavior does each input currently produce from this library when getRef() is called?
• How does the behavior change if we change from git/refs/%s to git/ref/%s?

GitHub API git/ref vs. git/refs

Here are four queries and the response from them:

• git/refs/heads/gh-pages
• git/refs/heads/gh
• git/refs/headz
• git/ref/heads/gh-pages
• git/ref/heads/gh
• git/ref/headz

git/refs/heads/gh-pages

{
  "ref": "refs/heads/gh-pages",
  "node_id": "MDM6UmVmNjE3MjEwOmdoLXBhZ2Vz",
  "url": "https://api.github.com/repos/hub4j/github-api/git/refs/heads/gh-pages",
  "object": {
    "sha": "bf902ab5c8aade1e5cbefa6db4cf39f5f3692552",
    "type": "commit",
    "url": "https://api.github.com/repos/hub4j/github-api/git/commits/bf902ab5c8aade1e5cbefa6db4cf39f5f3692552"
  }
}

git/refs/heads/gh

This is surprising. We get this same output for git/refs/heads and even git/refs/hea.

[
  {
    "ref": "refs/heads/gh-pages",
    "node_id": "MDM6UmVmNjE3MjEwOmdoLXBhZ2Vz",
    "url": "https://api.github.com/repos/hub4j/github-api/git/refs/heads/gh-pages",
    "object": {
      "sha": "bf902ab5c8aade1e5cbefa6db4cf39f5f3692552",
      "type": "commit",
      "url": "https://api.github.com/repos/hub4j/github-api/git/commits/bf902ab5c8aade1e5cbefa6db4cf39f5f3692552"
    }
  },
  {
    "ref": "refs/heads/master",
    "node_id": "MDM6UmVmNjE3MjEwOm1hc3Rlcg==",
    "url": "https://api.github.com/repos/hub4j/github-api/git/refs/heads/master",
    "object": {
      "sha": "dbd20fe396e13f7f6b7de5d6dfcbd9e6d8775129",
      "type": "commit",
      "url": "https://api.github.com/repos/hub4j/github-api/git/commits/dbd20fe396e13f7f6b7de5d6dfcbd9e6d8775129"
    }
  }
]

git/refs/headz

{
  "message": "Not Found",
  "documentation_url": "https://developer.github.com/v3/git/refs/#get-a-reference"
}

git/ref/heads/gh-pages

Identical to git/refs/heads/gh-pages above.

git/ref/heads/gh

{
  "message": "Not Found",
  "documentation_url": "https://developer.github.com/v3/git/refs/#get-a-single-reference"
}

git/ref/headz

{
  "message": "Not Found",
  "documentation_url": "https://developer.github.com/v3/git/refs/#get-a-single-reference"
}

Current github-api behavior using git/refs

TODO: Write tests verifying the demonstrating the current behavior.

New github-api behavior using git/ref

TODO: Update product code and modify tests to match the new behavior.

[bitwiseman]

Turns out there's a reason why this was not done: it breaks GHE 2.18 and earlier, possibly later as well.