Re: git non-time-sequential logs

> On Jan 4, 2021, at 9:05 AM, Alan Somers <asomers_at_FreeBSD.org> wrote:
> 
> On Mon, Jan 4, 2021 at 9:58 AM Poul-Henning Kamp <phk_at_phk.freebsd.dk <mailto:phk_at_phk.freebsd.dk>> wrote:
> 
>> --------
>> John Kennedy writes:
>> 
>>> This might be perfectly natural and just new to me, but when I look at
>> the
>>> git logs this morning I see things like this (editing by me):
>>> 
>>>      Date:   Mon Jan 4 17:30:00 2021 +0100
>>>      Date:   Mon Dec 14 18:56:56 2020 +0100
>>>      Date:   Tue Dec 15 13:50:00 2020 +0100
>>>      Date:   Mon Jan 4 16:23:10 2021 +0100
>>> 
>>>  I've always assumed that the "Date:" there was when the commit
>> happened,
>> 
>> It is, but it is the time it was committed in the first git repos it was
>> committed to,
>> in this case the repos of the committer in question.
>> 
>> Without taking a position on the merits of this design-choice, I
>> just want to point out that it means that timestamps should be
>> viewed very sceptically, since they depend on the *local* clock on
>> somebodys computer, not on the central repos machine.
>> 
> 
> I'll be more frank than phk: it sucks.  Git's commit dates are basically
> useless.  But there are a few ways to improve the situation:
> 1) If we start using Gitlab or something similar, we can ban pushes
> directly to head.  Then we'll be able to trust the Dates on Gitlab's merge
> commits.
> 2) Perhaps we can use the Git Notes to add a field for the Date when a
> commit was pushed to the master server?
> 3) The internet is full of suggestions for how to change the way commits
> are displayed locally to mediate this problem.  But they all seem to
> involve changes to the working copy's configuration, not the master's.  And
> I haven't gotten any way to work.

I actually find the non-sequential dates a feature: if someone reorders commits in a stack, e.g., `git rebase -I` I find it curious wondering why things were committed in the order they were.

The point is to stop looking at git like svn: commits should be done as larger bodies of work (merge commits), as opposed to single atomic commits.

Cheers,
-Enji