Re: Issue with lore GIT repo for linux-kernel

[Eric Wong <e@80x24.org>]

Matt Keenan <matt.keenan@oracle.com> wrote:
> Hi,
> 
> Reaching out to you as suggested by Konstantin (webmaster@kernel.org), to
> whom I sent the following email, and he recommended on contact you
> illustrating my suggestion that commits to lore mail lists can happily have
> any AuthorDate they want, but the CommitDate should really reflect the
> actual date/time the commit was made.

We actually try to extract the date from Received: headers for
CommitDate, but unfortunately the blob in question
(4ef2376a727a) lacks a Received: header...

> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> Just wanted to make you aware of something I find a little odd regarding the
> latest git shard for linux-kernel mailing list.
> 
> Commit: a3d6603dc01612c65db315bdcf980487293c41e9 to
> https://lore.kernel.org/lkml/10
> 
> This is the 30th anniversary of Linus's original post "What would you like
> to see most in minix?".
> 
> Because the AuthorDate for this message is 25-Aug-1991, the resulting
> CommitDate is also set to 25-Aug-1991, even though the actual commit to
> 10.git took place on 25-Aug-2021.
> 
> This breaks some git commands for 10.git. Specifically for those who want to
> use --after git option.
> 10.git contains emails from 10-May-2021 to the present day. If one wants to
> see messages from say 23-Aug-2021, one should be able to use the following :
> 
> $ git log --date=local --pretty='%H %cd' --after='2021-08-22 23:59:59'
> --before='2021-08-24 00:00:00'
> 
> This command sadly produces no output and all because of commit
> a3d6603dc01612c65db315bdcf980487293c41e9.

Oh well...  The message will still be indexed correctly by the
SQLite and Xapian code.  git-only operation has taken a backseat
in recent years and the expectation is at least SQLite is
available, if not Xapian.

> Git will start at HEAD, and check the CommitDate for each commit. If the
> CommitDate falls between the boundaries of --after and --before it's
> printed. Traversal will then cease when it reachs the first commit with a
> CommitDate older than --after.
> 
> Git therefore traverses only as far as
> a3d6603dc01612c65db315bdcf980487293c41e9, sees a date older than 22-Aug-2021
> and then stops.
> 
> Git is I presume making the assuption that all commits have CommitDate's
> that are in chronological order, however because of
> a3d6603dc01612c65db315bdcf980487293c41e9, commits to 10.git are not.
> 
> Therefore this commit sadly but effectively renders --after useless for the
> 10.git lkml repo for any dates prior to 26-Aug-2021.
> 
> I'm not a git expert, as such don't have any recommendations for possibly
> resolving this, or whether you feel this is something that needs to be
> resolved or not.

I'm thinking it's not worth resolving.  Hypothetically
Konstantin could use public-inbox-edit to add a Received:
header, but that would be disruptive to mirrors.

> I'm not a git expert, as such don't have any recommendations for possibly
> resolving this, or whether you feel this is something that needs to be
> resolved or not. Personally the AuthorDate for this commit can happily
> remain at 1991, but the CommitDate I think should really reflect when the
> actual commit to 10.git took place.

I think leaving things as-is for now is preferable.  The
expectation should be to have SQLite and/or Xapian available to
index.

> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 
> Anyhow I hope you find this information useful.

Sure, thanks.  I didnt know of people using git-only stuff.
Unfortunately, public-inbox is a combination of an unpopular
scripting language and unpopular license...