Issue with lore GIT repo for linux-kernel

Issue with lore GIT repo for linux-kernel

[Matt Keenan]

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.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

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.

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

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Anyhow I hope you find this information useful.

regards

Matt

Re: Issue with lore GIT repo for linux-kernel

[Eric Wong]

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