[lostintangent]

This is awesome! And it’s so exciting to see folks investing energy into this problem space.

Out of curiosity: did you add support for multiple backends because you don’t think Git will ultimately be sufficient for the experience you want to create? Or did you just want to ensure that the tool didn’t become unnecessarily coupled to Git?

[martinvonz]

Good question. You're right on both guesses. One reason is that I want to make sure the API works well enough that it's easy to replace the backend. The current native backend is called `local_store` because it stores files locally (just like the Git backend does). I want to be able to add another backend that fetches objects from a remote instead (and caches them locally), although another option is to hide that part inside the backend like Git does with its partial clone support. I also want to be able to add more functionality that the Git backend doesn't have. Maybe that would be tracking of renames, or maybe something I haven't though of yet.

[ParetoOptimal]

> I also want to be able to add more functionality that the Git backend doesn't have. Maybe that would be tracking of renames, or maybe something I haven't though of yet.

Awesome, that would enable a realistic no-risk path to adoption for most projects:

- trying jujutsu on work codebase

- if useful, tell a coworker and maybe they try it

- present internally about pros

- team tries and agrees its better, adopts it

- after some months confidence is built, give a presentation on features you could get with jujutsu native backend, gauge interests\worth