File history for renamed files, with '--follow' equivalent to show the complete history

[Chi-Iroh]

Fixes #28253

Added a checkbox in the file history, so that we can toggle following renames.

I made a test repo, with a first commit creating a file, and a second one renaming it.
Here is what the history looks.

Rename following disabled :

Rename following enabled :

As a reminder, here's what it looks like now :

However, I have a question: I inserted a small spacing between the text and the checkbox, and as 1em and 1rem looked too big, I put 5px instead. Is it OK to use an absolute size in this context ?

[wxiaoguang]

Thank you very much for the PR.

Although it needs more improvements to follow Gitea's code guideline, the idea is good enough.

I can help to make future improvements, before making more changes, I have some questions, see below.

[wxiaoguang]

IIRC "rev-list --count" was used intentionally because "log" is much slower (especially on a file with many commits)?

[Chi-Iroh]

I indeed saw commit 58a4407 which made the change, but its comment says --follow is slow, and not git log on its own, so I assumed git log was OK. If not, I'll gladly use rev-list by default.

[wxiaoguang]

If "rev-list --count" works, please use it as much as possible.

[Chi-Iroh]

Fixed in 6bf3c18
With lint fixes in 5f324be

[wxiaoguang]

Why checking ErrUnexpectedEOF? When it would happen?

[Chi-Iroh]

git log --pretty=format:%H output lacks a newline at the end, whereas git rev-list doesn't. So that's the fix I found to avoid error 500, please tell me if something better is needed.

[wxiaoguang]

I don't think ErrUnexpectedEOF is right, ErrUnexpectedEOF only means something wrong happens, so it needs a clear fix.

[Chi-Iroh]

I guess the core issue is in modules/git/repo_commit.go:279-281 :

length := objectFormat.FullLength()
commits := []*Commit{}
shaline := make([]byte, length+1)

From what I understand, shaline is expected to have a length of the hash's length + 1, presumably for the newline. So at line 283 (n, err := io.ReadFull(stdoutReader, shaline)), when the last output line is reached, only length bytes are read, instead of the expected length + 1 bytes, so it triggers ErrUnexpectedEOF.

If an EOF happens after reading some but not all the bytes, ReadFull returns ErrUnexpectedEOF.
https://pkg.go.dev/io#ReadFull

[wxiaoguang]

The commit history became a mess. Please follow git's manual to maintain the commits, and then force-push after fixing the problems.

And one more thing, when review starts and there is no special requirement, please avoid rebase&force-push.