On Wed, Jan 03, 2024 at 10:52:04PM +0000, Jamie Landeg-Jones wrote: > Brooks Davis <bro...@freebsd.org> wrote: > > > Nothing about dates is centralized in git, but some server side checks > > could be implemented on CommitDate. IMO we should require that > > CommitDate be >= the previous one and less than "now". > > Ah, I realised Linux doesn't like centralised dates, because of the > decentralisation of git, but I thought that as we grabbed from a > master repo, those commit dates would be in sync.
The dates are just strings in the commits. There's no central commit queue to rewrite the commits with new dates. The project could someday implment such a thing, but we deemed anything like that out of scope for the first phase of the migration. I do fine it quite annoying that the project has not implemented a check to monotonize CommitDate. Once upon a time clock drift between commit hosts might have been a concern, but hosts that can't stay in sync have no business committing directly. (I'd even be in favor of requiring the same for Date, effectively requiring rebase --ignore-date before each push, but there's much less concensus for that.) > Anyway, I think some sanity checking would be good. If nothing else, this > sort of thing breaks "git log": > > # git log --since=2023-02-02 --format="%cd %s %cn - %cd" > Wed Jan 3 17:08:58 2024 -0500 editors/cudatext: Update to 1.206.5 Jose Alonso > Cardenas Marquez - Wed Jan 3 17:08:58 2024 -0500 > Thu Jan 4 06:59:31 2024 +0900 net/qrcp: update to 0.11.1 Hiroki Tagato - Thu > Jan 4 06:59:31 2024 +0900 > Wed Jan 3 16:54:47 2024 -0500 lang/fpc-devel: Update to 3.3.1.20240103 Jose > Alonso Cardenas Marquez - Wed Jan 3 16:54:47 2024 -0500 > Wed Jan 3 16:54:46 2024 -0500 lang/fpc: fix stage-qa fails Jose Alonso > Cardenas Marquez - Wed Jan 3 16:54:46 2024 -0500 > Wed Jan 3 16:53:33 2024 -0500 sysutils/acpi_call: Check for errors from > copyout() Mark Johnston - Wed Jan 3 16:53:33 2024 -0500 > Wed Jan 3 15:37:13 2024 -0600 math/octave-forge-statistics-resampling: Update > to 5.5.3. Stephen Montgomery-Smith - Wed Jan 3 15:37:13 2024 -0600 > Wed Jan 3 23:00:58 2024 +0300 math/z3: Unbreak on i386 Gleb Popov - Wed Jan 3 > 23:00:58 2024 +0300 > Wed Jan 3 20:52:14 2024 +0100 devel/mongo-c-driver: Use USE_GITHUB helper and > always use (lib)utf8proc from ports Daniel Engberg - Wed Jan 3 20:52:14 2024 > +0100 > Wed Jan 3 22:26:11 2024 +0300 lang/ghc: Unbreak GHC 9.2 on AArch64, refresh > bootstraps. Gleb Popov - Wed Jan 3 22:26:11 2024 +0300 > > Note how I specified February 2023, yet the output stops as soon as it > reaches the recent entry with the rogue date. > > That makes the results corrupt, which may affect other things along the line. > > I notice the front page of Freshports doesn't even show the offending entries > in the list of recent commits, for example, whilst the individual port pages > shows the commits in the "wrong" order (i.e. the commits are displayed in > the perceived chronalogical order) Any general git tool or workflow that depends on dates being ordered can not work completely reliably. git log has the --since-as-filter to try to work around this, but even that is questionable since the dates are just a polite fiction without some sort of server-side enforcement. It's more stable and reliable to do something commit based like git log <commit-of-interest>..HEAD -- Brooks
