Gitlab site history date.

[Fred vS]

There's a strange change in the commit history list.
Until yesterday, the bold lines with the date indicated the commit date, but today it indicates the code creation date. (see picture)
Is this intentional?

[Martin_fr]

If it is so (and I don't know), then it probably was intentional on the site of GitLab (the company).

We don't change that. They update the site, and we get those updates when they decide. (well sometimes "features" from updates can be toggled by option, I don't know if that is the case here, but wouldn't think so)

Sometimes updates are rolled out to individual users, and some get it later....

----

Otherwise I am not sure about your observation. I git the 2 dates are named "author date" and "commit date" => IIRC in the past it was the "author date"  (And it seems to be on your image too, and also on my view of today’s gitlab)

I do recall that, because the question why those dates are sometimes going backwards has occasionally popped up. "commit dates" usually don't go backwards. "author dates" do go for and back. (if the commiter locally rebased)

What I do not know is, if the text has always read "name authored"

[marcov]

There are more changes. It doesn't list who merged it any more either ( Jane committed 9 weeks ago and John merged two days ago).  IIRC the old view had a combo on the right where you could select the sorting, just like the work items.

Personally I hate the "friendly" date indicators ("nn months ago"), without showing the full datetime stamp.

[Martin_fr]

Go to your preferences:

Time preferences

Configure how dates and times display for you. Learn more.
Use relative times
For example: 30 minutes ago.

[BildatBoffin]

The point of this thread, I think, is that "should it be the push date or the commit date". You can work on a branch for two months and finally squash it (or ammend it locally each time you change it) and then pick it up / merge it. I liked the previous system better too. You got the history in term of push but eventually the commit had another date.

[dsiders]

There are plenty of gitlab projects which do not use this altered commit layout. I'm more inclined to believe it's a project/group setting that got changed for the FPC projects.

If not... the enshitification of gitlab is nearly complete.

[Martin_fr]

The point of this thread, I think, is that "should it be the push date or the commit date". You can work on a branch for two months and finally squash it

I would have to check, but if you squash it, you create a new commit => wouldn't that give a new date? (Don't know maybe it keeps one of the existing...)
It may be kept if you you just rebase (including maybe re-order). Also maybe if you just amend?

And for that reason "commit" date is sometimes meaningless. If you make a merge request, then we will likely rebase it right before we merge it (Gitlab IIRC even allows a policy that enforces that). => But then the commit dates of all the commits in that branch will be changed.
So if you authored that long before, then that is lost.

Push isn't possible. Well GitLab could add it on top of git, but within git itself it can not exist.

Well, you would need to store the dates outside the commit.... => because if it was part of the commit, then when you push, it would be added, and that changes the SHA of your commit. But if you have other git clone/servers to sync with such a change would cause trouble.

Also a commit can be pushed to different remotes, and then each remote has a different date for that (another reason it couldn't be part of the commit)

So push date (as interesting as it sounds) doesn't work well (again, gitlab could store it outside of the git data, but that is some work for a tiny effect)

[Martin_fr]

There are plenty of gitlab projects which do not use this altered commit layout. I'm more inclined to believe it's a project/group setting that got changed for the FPC projects.

If not... the enshitification of gitlab is nearly complete.

Well I am not aware that we changed something.
And in the past such changes have rolled out over time, affecting some before others.

[Fred vS]

There are plenty of gitlab projects which do not use this altered commit layout. I'm more inclined to believe it's a project/group setting that got changed for the FPC projects.

If not... the enshitification of gitlab is nearly complete.

Well I am not aware that we changed something.
And in the past such changes have rolled out over time, affecting some before others.

Unfortunately, it seems that this is due to a change made by the GitLab developers, and there is no option for users to change this.

[marcov]

I think they just changed the view code to  a different paginated widget. Probably in time the other features will emerge.

Martin_fr: thanks, I now have sane datetimes again. So the only thing that I miss is datetime of the merge commit and who did that.

[Martin_fr]

So the only thing that I miss is datetime of the merge commit and who did that.

I never used the page much, always used my local git client (GUI). So I don't recall what it was before...

But, if you want to see merges, have you checked the commit graph? https://gitlab.com/freepascal.org/lazarus/lazarus/-/network/main?ref_type=heads

Yes, it is way less verbose... But you can see what was merged. An if you hover the DOT at the front of each commit, then it will give you details on that commit.

[n7800]

I remember the GitLab developers discussing redesigning this page for a while. But I see that the main discussion was about the filter and visual changes, and I can't find where (in the mentioned issue or on the bug tracker) they decided to change the sorting by date...

I have no proof, but it also seems to me that they were displayed in a different order before.

[n7800]

I still don't understand why they were upset about infinite scrolling, but they're cutting it out of the interface. I don't think that's right, it was very convenient...

Today, I had to search for commits in the browser, and scrolling with the wheel was replaced by multiple clicks of the "Next" button. Adjacent commits that end up on different pages are also difficult to visually compare.