There is at least two issues with how pijul clone works to my opinion.

1. It does not create a new directory for the cloned repository (it’s confusing, because all the other vcs I know of do that, but not a bug)
2. It appears like it deletes the current repository and recreates a new one; with zsh, it means once pijul clone is done, I need to cd to it nonetheless, which looks more like a bug to me

My report on this from discourse:

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

My understanding is that

$ pijul clone  /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 
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 

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?

Hi! Thanks for the report and discussion. I’ve pushed #35JBQQHC4TCYXUI3H4AEC3UBKRVHHDQTFCT54EV76NDSTETIYGYQC to fix this. Feel free to reopen if that doesn’t work for yous.