Re: git non-time-sequential logs

On 1/5/21 2:36 PM, John Baldwin wrote:
> On 1/4/21 8:52 AM, John Kennedy wrote:
>> On Mon, Jan 04, 2021 at 08:22:56AM -0800, John Kennedy wrote:
>>> The git logs in /usr/src aren't time-sequential, so maybe I shouldn't trust
>>> those dates above (I pulled it ~Jan 3rd and let it compile overnight), but
>>> I'm going to repull all the sources and recompile, just in case.  I might
>>> have initiall pulled it during the git conversion and maybe it is confused.
>> 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):
>>
>> 	commit e5df46055add3bcf074c9ba275ceb4481802ba04 (HEAD -> main, freebsd/main, freebsd/HEAD)
>> 	Author: Emmanuel Vadot <manu_at_FreeBSD.org>
>> 	Date:   Mon Jan 4 17:30:00 2021 +0100
>>
>> 	commit f61a3898bb989edef7ca308043224e495ed78f64
>> 	Author: Emmanuel Vadot <manu_at_freebsd.org>
>> 	Date:   Mon Dec 14 18:56:56 2020 +0100
>>
>> 	commit b6cc69322a77fa778b00db873781be04f26bd2ee
>> 	Author: Emmanuel Vadot <manu_at_freebsd.org>
>> 	Date:   Tue Dec 15 13:50:00 2020 +0100
>>
>> 	commit 4401fa9bf1a3f2a7f2ca04fae9291218e1ca56bf
>> 	Author: Emmanuel Vadot <manu_at_FreeBSD.org>
>> 	Date:   Mon Jan 4 16:23:10 2021 +0100
>>
>>    This is a fresh clone+pull off of anongit_at_git.FreeBSD.org:src.git.
>>
>>    I've always assumed that the "Date:" there was when the commit happened,
>> so they'd be increasing (most recent on top), but I suppose that you might
>> have developers in branches that are committing to their branch at one
>> point in time and it's getting merged into current (main) later, but the
>> original date is preserved?
>>
>>    I guess I only care because I was trying to use time to bisect the
>> time I thought the problem might have been introduced.
> For commits to gdb (which uses git), the project asks that all series be
> rebased via 'git rebase --ignore-date' prior to pushing to master to give
> monotonically increasing commit dates.  We could do something similar in
> FreeBSD either by asking folks to do that explicitly (though I know I
> sometimes forget when pushing to gdb myself), or we could avoid direct
> pushes to main.  One option some folks mentioned on IRC was to have a
> separate "staging" branch that developers push to and then have a bot that
> does a rebase --ignore-date of that branch to main periodically, though
> that opens the question of how to deal with cherry-picks to stable (for
> which asking developers to do a rebase --ignore-date prior to pushing is
> probably the simpler approach).
>
> If we did want monotonically increasing dates without having a staging
> branch, we could perhaps use a server-side push hook to reject them and
> developers would just have to do a rebase --ignore-date before pushing
> again.
>
In the example above, the commit dates *are* monotonically increasing.  
The author dates aren't however, and that's what the log shows.

Commit dates for direct changes to HEAD (seen in 'git log --first-parent 
--pretty=fuller' among other methods) seem like a direct replacement for 
SVN revisions and their timestamps.  Maybe I'm not understanding the 
problem?

To be extra sure commit dates remain monotonic, it would make sense to 
enforce by rule:
- The commit date must not be earlier than the date of the commit's parent.
- The commit date must not be in the future.
Is there any nonnegligible reason not to impose that as a protection 
against accidental system time misconfigurations?  In any other 
circumstance, it would not come into effect anyway?