> 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.