Use gitrepo.GetTreePathLatestCommit to get file lastest commit instead from latest commit cache

[lunny]

The latest commit cache is currently used only for listing tree files. However, a cold start may take longer than directly invoking the Git command. This PR addresses the issue of slow response times when accessing raw files, improving performance in such scenarios.

gitea.log:105521:2024/12/23 08:22:18 ...eb/routing/logger.go:68:func1() [W] router: slow      GET /xxxx/xxxxxx/raw/commit/xxxxxxxxxxxxxxxxxxxxxxxxxxx/.editorconfig for 172.18.0.5:53252, elapsed 3526.8ms @ repo/download.go:117(repo.SingleDownload)

[wxiaoguang]

Why in gitrepo package but not git package?

Do you have a clear plan or roadmap for these two packages? Or just keep making them more messy like other legacy/problematic code?

[lunny]

My plan is that modules/git will be the low level of modules/gitrepo. modules/gitrepo is only for managed repositories but modules/git will be a general git wrap library which can be used for managed repositories or temporary repositories. And in modules/gitrepo, the repository can be reused by context. There is a description in PR #28937 .

[wxiaoguang]

Then you shouldn't put "git command calls" in "gitrepo", right?

[lunny]

16506ad

[wxiaoguang]

If you are not able to remember the plan&design, please please please write documents and comments, in case you would forget how to write the right code next time.

[lunny]

Why do you think gitrepo should not invoke git command calls? Since git command calls are all the basics of almost all git operations, that will be unavoidable.

[wxiaoguang]

modules/gitrepo is only for managed repositories but modules/git will be a general git wrap library which can be used for managed repositories or temporary repositories.

It is answered by your description. Then the basic git operations should be provided by the "general git library", but not by a context-repo-manager.