Re: git repo port issues?

Brooks Davis <brooks@FreeBSD.org> wrote:

> 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
>
> From freebsd-current+bounces-5248-freebsd-lists=dyslexicfish.net@FreeBSD.org Wed Jan  3 23:26:23 2024
> Date: Wed, 3 Jan 2024 23:26:01 +0000
> From: Brooks Davis <brooks@FreeBSD.org>
> To: Jamie Landeg-Jones <jamie@catflap.org>
> Cc: brooks@FreeBSD.org, dvl@FreeBSD.org, yuri@FreeBSD.org,
>         freebsd-current@FreeBSD.org
> Subject: Re: git repo port issues?
> X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (donotpassgo.dyslexicfish.net [209.250.224.51]); Wed, 03 Jan 2024 23:26:23 +0000 (GMT)
>
> On Wed, Jan 03, 2024 at 10:52:04PM +0000, Jamie Landeg-Jones wrote:
> > Brooks Davis <brooks@freebsd.org> wrote:

> 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.

Ok, thanks for the clarification.

> 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.)

 [ ... ]

> 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.

I had a look at the documentation on since-as-filter - thanks, I understand
the issue now. Yeah, that option isn't suitable for large repos, as the
whole commit history has to be scanned, and as you say the actual values
are potentially meaningless.

A shame, I find update dates incredibly useful - far more than meaningless
commit hashes!

Anyway, seeing as the FreeBSD.org repo is the "main" repo in the FreeBSD
use case, if it was me, I'd patch it to ignore the user sent commit-date,
and use the local system date in its place, but obviously I don't know
the use cases and requirements like you guys do.

Still, I'm working on my campaign to get (at least) cgit date-aware for
files :-) - https://cgit.dyslexicfish.net/ports/latest/tree/
          - https://cgit.dyslexicfish.net/src/current/tree/

> git log <commit-of-interest>..HEAD

Thanks for the info. It's helped me a lot in my understanding of things.

Cheers, Jamie