Fix was merged and released upstream in libgit2 v1.1.0 (2020-10-12)
pygit2 compatibility as of v1.4.0 (2020-11-06)
I don't believe the fix requires any upstream changes.
It looks to me like the reported timestamp differences reflect the time at which tar was invoked. I can reproduce the behavior with a single tar file extracted to two directories.$ mkdir /tmp/first $ mkdir /tmp/second $ tar xzf 0.17.0.tar.gz -C /tmp/first $ tar xzf 0.17.0.tar.gz -C /tmp/second $ mtree -K sha256digest -cip /tmp/first > /tmp/first.txt $ mtree -K sha256digest -cip /tmp/second > /tmp/second.txt $ diff /tmp/first.txt /tmp/second.txt--- /tmp/first.txt Wed Dec 9 22:33:58 2020 +++ /tmp/second.txt Wed Dec 9 22:34:13 2020 @@ -1,14 +1,14 @@ -# tree: /tmp/first -# date: Wed Dec 9 22:33:58 2020 +# tree: /tmp/second +# date: Wed Dec 9 22:34:13 2020 # . /set type=file uid=1000 gid=0 mode=0755 nlink=1 -. type=dir nlink=3 time=1607571153.604606590 +. type=dir nlink=3 time=1607571182.794670190 # ./hg.sr.ht-0.17.0 - hg.sr.ht-0.17.0 type=dir nlink=5 time=1607571153.604606590 + hg.sr.ht-0.17.0 type=dir nlink=5 time=1607571182.794670190 .hg_archival.txt \ mode=0644 size=122 time=0.0 \ sha256digest=7323b7a7d3ba0752a3c4f74aad5c525640fc4910af99e30c62d1438899739035 @@ -54,7 +54,7 @@ # ./hg.sr.ht-0.17.0/.builds /set type=file uid=1000 gid=0 mode=0644 nlink=1 .builds type=dir mode=0755 nlink=2 \ - time=1607571153.574606440 + time=1607571182.764701552 alpine.yml size=1536 time=0.0 \ sha256digest=3ad1901a4de957607c1bc4415d9d1a03068104a24b059c596aad982aecfc50b9 archlinux.yml size=1142 time=0.0 \
I think the issue is in how the archive is generated with a randomized name before being sent. The "created with" name is visible on each download (contained in the .gz file) and triggers the checksum mismatch:$ file 0.17.0.tar.gz 0.17.0.tar.gz: gzip compressed data, was "0.17.0b'0c7421f703e0a468'.tar", last modified: Mon Nov 11 22:03:15 2019, max compression
I've submitted a patch that I think should fix this:
I can't point to when this was fixed, but this is working now.
I was able to
hg pushto a non-existent repository and received the expected "click here to create" prompt:
$ hg push ssh://firstname.lastname@example.org/~nprescott/example pushing to ssh://email@example.com/~nprescott/example searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files remote: remote: NOTICE remote: We saved your changes, but this repository does not exist. remote: Click here to create it: remote: https://hg.sr.ht/create?name=example remote: Your changes will be discarded in 20 minutes.
Should be fixed in 0.11.16 via 64cd1e04
Fixed in 0.62.2 via c08a9c71.
From a cold filesystem cache build times are over 11 seconds (~0.7 on subsequent runs). Noodling about caching strategies I'm thinking about using something like sqlite for a cache; it can store metadata like dates, parsed leaders etc. for sorting and creating an index in a structured format.
Especially in the case of static assets it seems like tracking file mtimes winds up re-implementing a bunch of
make. I would guess this would approximately double the size/complexity of the project -- is it worth it?
a blurb about static files around the mention of base href wouldn't be out of place
pipwill still pull down Jinja because it is an old release
Referring to this
post._date = self._parse_date(meta['date']) post.date = post._date.strftime('%Y-%m-%d')
Why do we even configure a date format in
Quoting the file directly
update times are reported in UTC with no offset
which is too simplified to be remotely correct. It isn't particularly hard to set some kind of offset - maybe make it a configuration parameter? It doesn't need to be great, but less wrong would be nice.