I believe this is now fixed via: https://lists.sr.ht/~sircmpwn/hare-dev/patches/31598
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