Wow, lots of different pieces. Thanks for the report.
My current plan is to phase out “integrated SSH” in Pijul itself. I wrote Thrussh in order to write the Nest, and now I want to stop supporting SSH here. Windows users who don’t want to bother with SSH (my primary target when I wrote the Thrussh client) will be able to push their patches in a secure way over HTTP, which will also be more efficient (and less confusing) with HTTP/3.
I’m still interested in your setup, if you don’t mind sharing/explaining it.
As for GVFS, Pijul operates on a datastructure stored on the disk, but only efficient (read: “usable”) when memory-mapped. I’m currently working on a slightly different solution, which will be able to operate fine (only less efficiently) even without mmap.
CXSCA5HNK3BSSUMZ2SZ5XNKSSHC2IFHPC35SMO5WMWVJBYEFSJTQC
Alright, this is fixed now, thanks!
Nice, thanks. Sorry for not getting back to you earlier, I currently don’t have time to investigate my side of the ssh issues.
Since ssh remotes don’t work for me (need to analyze this, but thrussh seems wildly incompatible with the keys used by my ssh installation), I tried mounting a directory with
gvfs
and then cloning from the mountpoint. Unfortunately, it bailed with this error:This seems as if there was something wrong with URL parsing, since the filename contains a colon and it tries to interpret the argument as an ssh remote. But the real problem is that opening the DB of the “remote” repo with
libpijul::pristine::sanakirja::Pristine::new(&dot_dir.join("db"))
fails and pijul then falls back to parsing the argument as an ssh remote without showing the earlier error to the user.Adding some debug statements reveals:
which suggests that
gvfs
simply doesn’t implement a file operation that Sanakirja tries to use.The better approach here would be to print an error message and exit whenever the sanakirja call fails, except if it’s a “file not found” error and only in the latter case fall through to ssh parsing.