Incorrect diffstat api result for changed files (Mercurial)

Issue #18034 resolved
Ankit Oswal created an issue

After executing https://api.bitbucket.org/2.0/repositories/bitbucket/geordi/diffstat/d222fa2..e174964

Result

{
  "pagelen": 500,
  "values": [
    {
      "status": "modified",
      "old": {
        "path": "setup.py",
        "type": "commit_file",
        "links": {
          "self": {
            "href": "https://api.bitbucket.org/2.0/repositories/bitbucket/geordi/src/e1749643d655d7c7014001a6c0f58abaf42ad850/setup.py"
          }
        }
      },
      "lines_removed": 1,
      "lines_added": 2,
      "new": {
        "path": "setup.py",
        "type": "commit_file",
        "links": {
          "self": {
            "href": "https://api.bitbucket.org/2.0/repositories/bitbucket/geordi/src/6aac8f0c4735789eb491b585d34189ea1adafb04/setup.py"
          }
        }
      },
      "type": "diffstat"
    }
  ],
  "page": 1,
  "size": 1
}

The 'href' of the new file points to

https://api.bitbucket.org/2.0/repositories/bitbucket/geordi/src/6aac8f0c4735789eb491b585d34189ea1adafb04/setup.py

When we access this url, we get

{"type":"error","error":{"message":"Changeset not found."}}

Clearly the sha1/commit id in the response url for new files list is incorrect.

Comments (6)

  1. Daniel Roth

    I just came across the same issue. It seems to be only when the {spec} is a commit range using double dot notation. If you changed the request to just be https://api.bitbucket.org/2.0/repositories/bitbucket/geordi/diffstat/d222fa2 it properly returns the new self href.

    One workaround for this would be to replace the hash in the new self href with the latest hash requested (d222fa2 in your example). So essentially replace 6aac8f0c4735789eb491b585d34189ea1adafb04 with d222fa2 in the result. This will result in the final href being https://api.bitbucket.org/2.0/repositories/bitbucket/geordi/src/d222fa2/setup.py

    This adds complexity because you now need to parse the response and change the hash but it does circumvent the problem until a proper solution is implemented by BitBucket or the behaviour is explained.

  2. Robin Stocker staff

    Hey! Thanks for reporting this. This was a bad example from our documentation, coupled with a bug that had old/new the wrong way around.

    Instead of "new..old", it should be "old..new". So for the geordi example, try this now:

    https://api.bitbucket.org/2.0/repositories/bitbucket/geordi/diffstat/e174964..d222fa2

    With that, the old and new links make sense:

          "old": {
          ...
                "href": "https://api.bitbucket.org/2.0/repositories/bitbucket/geordi/src/e1749643d655d7c7014001a6c0f58abaf42ad850/setup.py"
          ...
          "new": {
          ...
                "href": "https://api.bitbucket.org/2.0/repositories/bitbucket/geordi/src/d222fa235229c55dad20b190b0b571adf737d5a6/setup.py"
    

    (With new..old, what happens is that a temporary "merge commit" is created to compare them. That is the 6aac8f0 that you see in the response, but that merge commit is not stored in the repository.)

  3. Log in to comment