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 <m...@freebsd.org>
Date: Mon Jan 4 17:30:00 2021 +0100
commit f61a3898bb989edef7ca308043224e495ed78f64
Author: Emmanuel Vadot <m...@freebsd.org>
Date: Mon Dec 14 18:56:56 2020 +0100
commit b6cc69322a77fa778b00db873781be04f26bd2ee
Author: Emmanuel Vadot <m...@freebsd.org>
Date: Tue Dec 15 13:50:00 2020 +0100
commit 4401fa9bf1a3f2a7f2ca04fae9291218e1ca56bf
Author: Emmanuel Vadot <m...@freebsd.org>
Date: Mon Jan 4 16:23:10 2021 +0100
This is a fresh clone+pull off of anon...@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?
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
