3 ms·

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

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 5y ago
> 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