Local clones and pulls do not work
Steps to reproduce:
$ sl clone https://github.com/docker/roadmap exa
$ sl clone exa exa2
abort: working copy is missing information or corrupt: unable to read gitdir: `No such file or directory (os error 2)
This also happens with SL_AUTOMATION=1 and/or ¡SL_CONFIG_FILE=/dev/null.
Similarly, pulling from a local sapling repository does not work (though pulling from a local git repo does), as sapling apparently expects a git repo when pulling.
$ sl clone https://github.com/docker/roadmap exa
$ sl init --git exa2
$ cd exa2
$ sl paths -a default ../exa
$ sl pull
pulling from /private/tmp/exa
abort: git command failed with exit code 128
git '--git-dir=/private/tmp/exa2/.sl/store/git' ls-remote --refs /private/tmp/exa refs/heads/main refs/heads/master
fatal: '/private/tmp/exa' does not appear to be a git repository
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.
Using an absolute path or a file:// url for the repository path results in the same error.
I got this to work by doing sl clone file:///localhost/path on a previous release of sapling, but then after I upgraded sapling, the existing repo stopped working (with some "repo is not a Github Enterprise repository" or some error), and I can't clone anymore either.
@rbehrends I believe this should be fixed in the most recent release?
I'm afraid not. I'm now getting a different error message when trying to clone a local repo.
$ sl clone https://github.com/docker/roadmap exa
$ sl clone exa exa2
abort: No such file or directory: /private/tmp/exa2/.sl/store/gitdir
$ sl --version
Sapling 0.1.20221208-212056-r520df27a
After this, exa2 contains a partially initialized .sl directory, which is however missing the store/git and store/gitdir entries.
Trying to pull fails with the same error message as before.
@rbehrends the failure seems legitimate, though in terms of prioritization, what is your goal? At Meta, it is common to have exactly one clone of our megarepo and switch between branches to work on different features.
It is not a huge priority, since (1) sl share covers a number of use cases and (2) cp -a is a workaround in most other cases. That said, I have situations, such as smaller repos containing versioned test data, where I want each clone to be fenced off against unwanted (especially programmatic) changes and where cp -a due to its total lack of safeguards is less than optimal and I'd rather clone and/or pull.
In addition, while not mentioned above, the same problem occurs when cloning a Sapling repo on an ssh server. You have to maintain a git repo on the ssh server, as far as I've been able to ascertain so far.
As an aside, while I also often work from a monorepo, I'll note that switching between branches is sometimes not practical (especially if a you have an expensive build step), but sl share covers that use case better already (and with less hassle than git worktree). Still, as mentioned above, there are plenty of other use cases where a separate clone is more desirable.