What I mean is that you can't co-locate your Sapling repository with your Git repository (at least, for now). You have to have them in separate directories and push/pull between them.
git-branchless is only an extension to Git, so it naturally operates in the Git repository. Jujutsu has a mode to create the `.jj` directory alongside the `.git` directory and co-locate them, which I find very convenient in practice. (Originally, Jujutsu only supported Git compatibility in the same way as Sapling, via pushes and pulls, but they added co-location later.)
> Looks like it calls out to the git executable occasionally
I believe Jujutsu never calls out to Git, and that all of its `jj git` interop commands are implemented via direct bindings to libgit2. This is less fragile in many ways, but it can also mean that `jj git` interop might be missing some new feature from Git. Fortunately, you can oftentimes just run the Git command directly in the repository when co-locating.
> presumably works on the git object model under the hood
There's no guarantee of this: the Mercurial (and therefore possibly Sapling?) revlog model is a little different from the Git object model, as I understand it. But it doesn't really matter, as long as it interoperates seamlessly. For now, I believe they do literally have a `.git` directory somewhere under the `.sl` directory, but they reserve the right to change that.
> > Looks like it calls out to the git executable occasionally
>
> I believe Jujutsu never calls out to Git
Oh, I was referring to Sapling. I know even less about Jujutsu than I do about Sapling!
> > presumably works on the git object model under the hood
>
> There's no guarantee of this ... but they reserve the right to change that
Interesting. So it would translate between them whenever you push to or pull from a Git repo?
I'm very keen to use Sapling if it's basically a polished interface to Git but less keen if it's an entirely different object model, because then I'm going to have to learn more about what's going on under the hood to understand it properly.
> Oh, I was referring to Sapling. I know even less about Jujutsu than I do about Sapling!
I was just remarking about Jujutsu, in the case that it was important to you for some reason whether or not your VCS called out to Git.
> Interesting. So it would translate between them whenever you push to or pull from a Git repo?
To be honest, I don't know. I suspect that, for now, they store real Git objects, rather than translating on the fly. You'd have to ask a Sapling maintainer.
> I'm very keen to use Sapling if it's basically a polished interface to Git but less keen if it's an entirely different object model, because then I'm going to have to learn more about what's going on under the hood to understand it properly.
I might have muddled some layers of abstraction and brought up something unhelpful. Git's object database and Mercurial's revlog are more comparable in terms of where they lie in the abstraction hierarchy, but these are just the storage layers. In practice, I find the Git and Mercurial object models, as exposed to the user, to be similar enough that I pretty much never have to worry about the differences. (Well, perhaps it's true that Mercurial file contents are not addressed by blob hashes, but do I ever really want to address by "blob hash", or just by "the contents of this file at this commit"?)
What I meant to emphasize is that you can't directly use Git to access Mercurial/Sapling's internal object store, if that's important to you (perhaps for scripting). In comparison, with Jujutsu, if you modify the Git object store on disk, it will try to "import" refs the next time you invoke it in order to update its own internal object store to match.
git-branchless is only an extension to Git, so it naturally operates in the Git repository. Jujutsu has a mode to create the `.jj` directory alongside the `.git` directory and co-locate them, which I find very convenient in practice. (Originally, Jujutsu only supported Git compatibility in the same way as Sapling, via pushes and pulls, but they added co-location later.)
> Looks like it calls out to the git executable occasionally
I believe Jujutsu never calls out to Git, and that all of its `jj git` interop commands are implemented via direct bindings to libgit2. This is less fragile in many ways, but it can also mean that `jj git` interop might be missing some new feature from Git. Fortunately, you can oftentimes just run the Git command directly in the repository when co-locating.
> presumably works on the git object model under the hood
There's no guarantee of this: the Mercurial (and therefore possibly Sapling?) revlog model is a little different from the Git object model, as I understand it. But it doesn't really matter, as long as it interoperates seamlessly. For now, I believe they do literally have a `.git` directory somewhere under the `.sl` directory, but they reserve the right to change that.