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]

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

[Chi-Iroh]

@wxiaoguang So, do I need to change something, or ErrUnexpectedEOF is fine ?

[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.

[Chi-Iroh]

@wxiaoguang I'll be glad to fix what you'd like, but could you tell me what exactly is wrong ? I genuinely don't know what to do about the commits and don't understand why you said it's a mess.
Also, the forced pushes were because I made a mistake / forgot something important in a commit I just pushed, sorry for these.

And last, what about the failing checks ? The frontend one is because of a change silvermind asked me to do, and as far as I understand, the vulnerability one is unrelated with what I changed.

[wxiaoguang]

I don't know what you have done on your side.

Now, these pages contains unrelated changes:

• https://github.com/go-gitea/gitea/pull/34686/commits
• https://github.com/go-gitea/gitea/pull/34686/files

[Chi-Iroh]

Ok, that's because I thought I ought to update my branch to upstream to check I didn't break something, so that's why these commits are here. I'll drop them with a rebase, is it ok for you ?