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

[Chi-Iroh]

#34686
I accidentally deleted the PR fork (I had many ones), so afaik I'm forced to create another PR.
Sorry for the inconvenience.

[Taldariner]

Hello!
Is there any updates on this PR?
Would be very grateful if this feature were added.

[Chi-Iroh]

Hi @Taldariner !

My changes weren't approved as maintainers had to study some technical details, see here: #34686 (comment)

And it's my first contribution to this project, so it unfortunately slows the process down.

[Taldariner]

Hi, @Chi-Iroh !

I read that conversation, but looks like after PR recreation process stubbed a little bit.

But anyway, I got it, hope it will be merged soon, and thank you for that work!

[lunny]

Could you post a screenshot and please have a test for the rename behavior.

[wxiaoguang]

• File history for renamed files, with '--follow' equivalent to show the complete history #34686 (comment)

I can see there are still some problems in code, for example: we can't depend on the unstable ErrUnexpectedEOF behavior (there are other cases causing such error, and then the data would be wrong); the query parameter needs a complete backend implementation because users need to navigate between pages when the commits number is large; it needs some tests to cover the new behavior of CommitsByFileAndRange

It needs to be refactored & cleaned up first

[Chi-Iroh]

Could you post a screenshot and please have a test for the rename behavior.
@lunny

Comes from my very first message in #34686

[Chi-Iroh]

@wxiaoguang I managed to change the format string in git log --follow to have a newline at the end, so I don't rely on ErrUnexpectedEOF anymore.

[Chi-Iroh]

I'm facing an issue regarding my commits : as many commits were pushed to Gitea upstream since I made my fork, I have some conflicts.
Locally, I merged my branch with the upstream main to solve conflicts, but I have more than a thousand changes due to the commits on the upstream.
To keep the PR clean, what would you like me to do ? A commit containing solely the changes to fix the conflicts ? If so, my branch won't build as it will lack some recent changes.
Sorry for the inconvenience, I'm not sure how to proceed.

[lunny]

You can use Gitea’s main branch as the base branch when creating your pull request. After it’s merged, simply merge the main branch back into your private branch to keep it up to date.