[x]): N/A.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
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.
Most helpful comment
I submitted a fix.
Unfortunately the
gitmodule API was historically shaped in quite ad-hoc way which resulted in numerous quirks. While normallyTreeEntry.Name()returns only the name without a path (and some other functions depend on that) in case it is listed throughTree.ListEntriesRecursivelyit returns the path relative to the referenced tree. This was added some time after my originalgo-gitmigration 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=1parameter 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-gitbranch 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 likeHEAD). 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.