Pijul clone's directory handling

1

I’ve been playing around with the new pijul a bit, and found some odd behaviour around cloning.

(This may well be on your list already – feel free to ignore. Thought I’d record it just in case. Also let me know if this should go elsewhere. I haven’t been able to connect to nest.)

My understanding is that

$ pijul clone <remote> /path/to/dest

clones a repository to the destination directory (so that /path/to/dest would be the repository top level).

So e.g. to clone pijul (hypothetically), I’d do something like:

$ cd ~/src
$ pijul clone https://nest.pijul.org/pijul/pijul pijul

which would work fine. Where things get weird is if you omit the destination path argument, in which case pijul defaults to the current working directory. This has some weird consequences:

$ cd /src
$ pijul clone <remote>
Error: Permission denied (os error 13) at path "/.tmpawuSmZ"

(pijul clones into a temporary sibling director to the destination, which in this case is in read-only /.)

$ cd ~src
$ mkdir dest
$ cd dest
$ pijul clone <remote>

This successfully clones the repo into ~/src/dest (which will no longer be empty), but my current working directory has been moved out from under me (working directory is still empty, and my shell still thinks I’m in ~/src/dest, but actually I need to call cd ../dest to get what might be the expected result).

…

The obvious fix for this would be to default the destination path to some name derived from the remote, like git does (so that pijul clone https://.../pijul would clone into ./pijul instead of .). Otherwise, maybe require an explicit destination path argument?

1 Like
2

I ran into similar issues, and created an issue on the Nest. Your report is way better than mine, though. Do you think you could post it there? or, authorize use to copy it for you?

Thanks!

1 Like
3

Done. Thanks for the pointer, it seems I was trying to connect to the wrong nest.

1 Like