`file-contents` API returns `size: 0` for directories, should return Git tree object size

[rickyma]

Bug Description

When using the file-contents API to request information about a directory, the returned JSON always sets the "size" field to 0 for directories. This is misleading, as the Git tree object for the directory does have a size, which can be retrieved using native Git commands.

Example response:

[
  {
    "name": "batch_test",
    "path": "batch_test",
    "sha": "46b22fae3e0ac92b73989ca912a6d7dacd3975ab",
    "type": "dir",
    "size": 0,
    ...
  }
]

Expected Behavior

The "size" field for a directory should reflect the actual size of the corresponding Git tree object, which can be obtained using the following Git command:

git cat-file -s $(git rev-parse HEAD:batch_test)

This would provide the real byte size of the tree object, rather than always returning 0.

Why is this important?

• Returning the actual tree object size is more accurate and useful for clients that want to understand the underlying Git data structure.
• It aligns the API response with the real state of the repository, and is consistent with how file blobs are handled.

Steps to Reproduce

1. Create a directory in a repository.
2. Query the file-contents API for that directory.
3. Observe that "size" is always 0, regardless of the actual tree object size.

Suggested Fix

• For entries of "type": "dir", set the "size" field to the size of the corresponding Git tree object, as returned by git cat-file -s <tree-oid>.

Additional Information

• Gitea version: Latest
• Example API endpoint: /repos/{owner}/{repo}/file-contents

Thank you for your attention!

[wxiaoguang]

I don't think it is important or any client would really need that "tree object size", I do not see the "tree object size" can be used for any purpose or to help to make any decision.

In real world, if you do ls, you also see some "directory sizes" in some file systems, but I don't think you ever used it. The only useful size is "file size".

[rickyma]

Thank you for your quick response and for sharing your perspective.
Since the API already exposes the blob size for files, exposing the tree size for directories would make the API more consistent and transparent.
I agree that this information may not be needed by most users, but for advanced use cases, it can be valuable. At least in my case, we would like to have this size accurately set.

Would it be possible to at least make this information available?

[wxiaoguang]

but for advanced use cases, it can be valuable

What's the value?

Would it be possible to at least make this information available?

I believe it only causes confusions to most users.

[rickyma]

I believe it only causes confusions to most users.

Yeah, I get your point. I’ll try to find another way to get what I need. Thanks.