Group commit list page by date

[kerwin612]

[wxiaoguang]

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?

[delvh]

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.

[wxiaoguang]

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

[wxiaoguang]

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

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

[lunny]

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.

[delvh]

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

[kerwin612]

Complete the grouping design within the existing table.

[silverwind]

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

[sonjek]

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.

[techknowlogick]

@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).

[wxiaoguang]

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.

[kerwin612]

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

[metiftikci]

just a nit may forgatten

Suggested change

	<div class="commit_sign_badge">
	<div class="commit-sign-badge">

[wxiaoguang]

Actually it is a wrong class ......

The real class="commit-sign-badge" is only used in commit_sign_badge.tmpl

[wxiaoguang]

Still the question, it seems that "wiki" is still using the repo/commits_list, why not unify them to the new layout? Is there any strong reason that wiki must have a different layout?

[wxiaoguang]

I do not think this algorithm is right, or maybe it is right but it needs some tests.

For example:

• commit1 is at "2025-04-10T08:00:00+08:00"
• commit2 is at "2025-04-09T23:00:00-01:00"

Actually they are the same timestamp (1744243200), and the day depends on visitor's timezone.

• When visitor's timezone is UTC, time is 2025-04-10T00:00:00Z, on local day "2025-04-10"
• When visitor's timezone is -04:00, time is 2025-04-09T20:00:00-04:00, on local day "2025-04-09"

ps: I have no idea how GitHub handles such timezone problem then renders the "date" to end users. Just FYI.

Or maybe some tests could help to clarify the expected behavior.

[wxiaoguang]

Another edge case: git commit's date could be manually set.

So you could see a commit list like this:

commit4 2025-04-10
commit3 2025-04-01
commit2 2025-04-30
commit1 2025-04-15

And the graph is commit1->commit2->commit3->commit4.

What's the expected output for such commit list? It needs some tests to clarify the behavior.