To be honest, I like the old UI.

Although the new UI follows GitHub, it seems too loose and less informative.

What are the benefits of introducing the new UI?

I can see what you mean for repos that only you yourself contribute to:
I mean, how many commits can you commit in a day? 1? 2?

But precisely for repos with a large number of contributors and commits like Gitea, this feature is absolutely useful:
It helps you distinguish where in the timeline you currently are, and also on what date you are (if you go a few pages down the list).
At the moment, this somewhat crucial information for the commit list is "hidden" behind a (mostly) relative tooltip like a month ago.

I can see what you mean for repos that only you yourself contribute to:

I never meant that.

But precisely for repos with a large number of contributors and commits like Gitea, this feature is absolutely useful:
It helps you distinguish where in the timeline you currently are, and also on what date you are (if you go a few pages down the list).

The old list is pretty clear, and contains all information.

Why end users need to "distinguish where in the timeline you currently are" by the unit of "day"?

At the moment, this somewhat crucial information for the commit list is "hidden" behind a (mostly) relative tooltip like a month ago.

Then we just need to change it to the absolute time, or set PREFERRED_TIMESTAMP_TENSE in app.ini

From another perspective, there are so many pending proposals and bug reports, till now, I do not see any single user said that they need the "grouped commit list".

I mean, how many commits can you commit in a day? 1? 2?

Off-topic: how many ? 4? 5? 6?

I think you only need to update the frontend and keep the backend as it is. There’s no need to group commits on the backend.

Why end users need to "distinguish where in the timeline you currently are" by the unit of "day"?

Something I've noticed doing myself is the following:
From time to time, I watch over what happened in vim/vim since I last looked at the repo for a quick overview of changes to expect.
When the currently looked at date is publicly displayed, it's much easier to know the last time you've looked at the repo.

Alternatively, consider any fork that wants to see what changed upstream since the last cherry-pick.
When you know the day of the last cherry-pick, it becomes much easier to find the diff of commits visually.
(And yes, I am aware of the contextual irony in this argument. I haven't found a way to phrase it without triggering that association. )

Complete the grouping design within the existing table.

3000-gogitea-gitea-y4ulxr46c4k ws-us118 gitpod io_test_test_commits_branch_main (1)

I like the design with the timeline and icons from first screenshot better, it matches the issue/pr view.

Hi, I like the first proposed change. It's follows GitHub/GitLab style.
Without this separation, it's harder to control which new commits have appeared since the previous review.
The new order is also easier to read, because the most important data is in front of your eyes and the commit SHA is secondary information.

@delvh I use the date separation for a similar reason where as a packager of software for various OSes I need to catch up on what's changed, as well it helps me verify some things for changelogs on projects that don't use milestones (or use PRs for changes).

I like the design with the timeline and icons from first screenshot better, it matches the issue/pr view.

If most people like GitHub style, feel free to ignore my comment for the old style.

This commit adds date grouping rows based on the optimization of the existing table:
b29d401
This commit and subsequent ones follow the date grouping design from GitHub's redesign:
0581b27