Gitea: Git Trees API no longer returns absolute paths + fails to find any other sha apart from head.

Created on 1 May 2019  路  2Comments  路  Source: go-gitea/gitea

  • Gitea version (or commit ref): eb8632b/master.
  • Git version: 2.11.0
  • Operating system: N/A.
  • Database (use [x]): N/A.
  • Can you reproduce the bug at https://try.gitea.io: N/A.

Description

According to https://developer.github.com/v3/git/trees/. The paths returned should be absolute paths like so:

{
  "sha": "fc6274d15fa3ae2ab983129fb037999f264ba9a7",
  "url": "https://api.github.com/repos/octocat/Hello-World/trees/fc6274d15fa3ae2ab983129fb037999f264ba9a7",
  "tree": [
    {
      "path": "subdir/file.txt",
      "mode": "100644",
      "type": "blob",
      "size": 132,
      "sha": "7c258a9869f33c1e1e1f74fbb32f07c86cb5a75b",
      "url": "https://api.github.com/repos/octocat/Hello-World/git/7c258a9869f33c1e1e1f74fbb32f07c86cb5a75b"
    }
  ],
  "truncated": false
}

However, the path being returned is only the filename, like so:

{
  "sha": "fc6274d15fa3ae2ab983129fb037999f264ba9a7",
  "url": "https://api.github.com/repos/octocat/Hello-World/trees/fc6274d15fa3ae2ab983129fb037999f264ba9a7",
  "tree": [
    {
      "path": "file.txt",
      "mode": "100644",
      "type": "blob",
      "size": 132,
      "sha": "7c258a9869f33c1e1e1f74fbb32f07c86cb5a75b",
      "url": "https://api.github.com/repos/octocat/Hello-World/git/7c258a9869f33c1e1e1f74fbb32f07c86cb5a75b"
    }
  ],
  "truncated": false
}

It doesn't seem to be able to find any other sha than head either:

https://i.imgur.com/rW3mREC.png
https://i.imgur.com/Qdm4S22.png

Commit which introduced this bug: https://github.com/go-gitea/gitea/commit/2af67f6044af1cad7136ce8c123e37ab090ca9bc

modules/git/tree.go

kinbug

Most helpful comment

I submitted a fix.

Unfortunately the git module API was historically shaped in quite ad-hoc way which resulted in numerous quirks. While normally TreeEntry.Name() returns only the name without a path (and some other functions depend on that) in case it is listed through Tree.ListEntriesRecursively it returns the path relative to the referenced tree. This was added some time after my original go-git migration branch in December and I didn't notice it when rebasing on top of newer Gitea versions. Unlike the regular Git Trees API the request version with ?recursive=1 parameter is not properly tested in the test suite.

The issue with the hashes not being properly resolved also happened when I was upgrading the go-git branch to newer Gitea version. However, in this case it's a quirk that comes from the GitHub API itself. Contrary to the documentation the API accepts both commit hash or tree hash as a parameter. The Gitea test suite only tests the case with commit hash (or symbolic name like HEAD). While my original implementation correctly resolved tree hashes I inadvertently introduced the bug when trying to pass the Gitea test suite and started resolving only commit hashes (and symbolic names) instead.

All 2 comments

That was certainly unintended and the file name part should be easy to fix. I'll see if I can reproduce the other part of the bug too.

I submitted a fix.

Unfortunately the git module API was historically shaped in quite ad-hoc way which resulted in numerous quirks. While normally TreeEntry.Name() returns only the name without a path (and some other functions depend on that) in case it is listed through Tree.ListEntriesRecursively it returns the path relative to the referenced tree. This was added some time after my original go-git migration branch in December and I didn't notice it when rebasing on top of newer Gitea versions. Unlike the regular Git Trees API the request version with ?recursive=1 parameter is not properly tested in the test suite.

The issue with the hashes not being properly resolved also happened when I was upgrading the go-git branch to newer Gitea version. However, in this case it's a quirk that comes from the GitHub API itself. Contrary to the documentation the API accepts both commit hash or tree hash as a parameter. The Gitea test suite only tests the case with commit hash (or symbolic name like HEAD). While my original implementation correctly resolved tree hashes I inadvertently introduced the bug when trying to pass the Gitea test suite and started resolving only commit hashes (and symbolic names) instead.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Fastidious picture Fastidious  路  3Comments

BRMateus2 picture BRMateus2  路  3Comments

BNolet picture BNolet  路  3Comments

cookiengineer picture cookiengineer  路  3Comments

thehowl picture thehowl  路  3Comments