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