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

Closed
opened 2025-11-02 05:06:20 -06:00 by GiteaMirror · 2 comments
Owner

Originally created by @Kasi-R on GitHub (May 1, 2019).

  • 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: 2af67f6044

modules/git/tree.go

Originally created by @Kasi-R on GitHub (May 1, 2019). - 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: ```json { "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: ```json { "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
GiteaMirror added the type/bug label 2025-11-02 05:06:20 -06:00
Author
Owner

@filipnavara commented on GitHub (May 1, 2019):

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.

@filipnavara commented on GitHub (May 1, 2019): 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.
Author
Owner

@filipnavara commented on GitHub (May 1, 2019):

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.

@filipnavara commented on GitHub (May 1, 2019): 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.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#3276