From be0ad55309c8d73fd79401e728ec945bf59df3e7 Mon Sep 17 00:00:00 2001 From: Martin von Zweigbergk Date: Fri, 21 Mar 2025 08:47:50 -0700 Subject: [PATCH] doc: update some references to "the native backend" --- README.md | 9 ++------- docs/design/run.md | 14 +++++++------- docs/design_docs.md | 4 ++-- docs/glossary.md | 9 ++++----- 4 files changed, 15 insertions(+), 21 deletions(-) diff --git a/README.md b/README.md index d21faab01..cf825fc02 100644 --- a/README.md +++ b/README.md @@ -212,17 +212,12 @@ the header of the website when you scroll to the top of any page. ### Compatible with Git Jujutsu is designed so that the underlying data and storage model is abstract. -Today, it features two [backends]—one of them uses a Git repository for storage, -while the other is a native storage backend[^native-backend]. The Git backend -uses the [libgit2](https://libgit2.org/) C library and the +Today, only the Git backend is production-ready. The Git backend uses the +[libgit2](https://libgit2.org/) C library and the [gitoxide](https://github.com/Byron/gitoxide) Rust library. [backends]: https://jj-vcs.github.io/jj/latest/glossary#backend -[^native-backend]: At this time, there's practically no reason to use the native -backend. The backend exists mainly to make sure that it's possible to eventually -add functionality that cannot easily be added to the Git backend. - The Git backend is fully featured and maintained, and allows you to use Jujutsu with any Git remote. The commits you create will look like regular Git commits. You can fetch branches from a regular Git remote and push branches to the diff --git a/docs/design/run.md b/docs/design/run.md index a28abf1c1..6a2128f90 100644 --- a/docs/design/run.md +++ b/docs/design/run.md @@ -34,13 +34,13 @@ the git-hook model, there was consensus about not repeating their mistakes. For `jj run` there is prior art in Mercurial, git branchless and Google's internal Mercurial. Currently git-branchless `git test` and `hg fix` implement -some kind of command runner. The Google internal `hg run` works in -conjunction with CitC (Clients in the Cloud) which allows it to lazily apply -the current command to any affected file. Currently no Jujutsu backend -(Git, Native) has a fancy virtual filesystem supporting it, so we -can't apply this optimization. We could do the same once we have an -implementation of the working copy based on a virtual file system. Until then, -we have to run the commands in regular local-disk working copies. +some kind of command runner. The Google internal `hg run` works in conjunction +with CitC (Clients in the Cloud) which allows it to lazily apply the current +command to any affected file. Currently no open-source Jujutsu backend (Git, +Simple) has a fancy virtual filesystem supporting it, so we can't apply this +optimization. We could do the same once we have an implementation of the working +copy based on a virtual file system. Until then, we have to run the commands in +regular local-disk working copies. ## Goals and Non-Goals diff --git a/docs/design_docs.md b/docs/design_docs.md index ba5a425e4..34633b1a9 100644 --- a/docs/design_docs.md +++ b/docs/design_docs.md @@ -4,10 +4,10 @@ Jujutsu uses Design Docs to drive technical decisions on large projects and it is the place to discuss your proposed design or new component. It is a very thorough process, in which the design doc must be approved before PRs for the feature will be accepted. It shares some similarities with [Rust RFCs] but -mostly addresses _technical_ problems and gauges the technical and social +mostly addresses _technical_ problems and gauges the technical and social concerns of all stakeholders. -So if you want to start building the native backend or the server component for +So if you want to start building a native backend or the server component for Jujutsu, you'll need to go through this process. ## Process diff --git a/docs/glossary.md b/docs/glossary.md index dc9eae948..74b27d929 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -10,11 +10,10 @@ stores a list of [heads](#head) of such branches. ## Backend -A backend is an implementation of the storage layer. There are currently two -builtin commit backends: the Git backend and the native backend. The Git backend -stores commits in a Git repository. The native backend is used for testing -purposes only. Alternative backends could be used, for example, if somebody -wanted to use jj with a humongous monorepo (as Google does). +A backend is an implementation of the storage layer. There is currently only one +production-ready builtin commit backend: the Git backend. The Git backend stores +commits in a Git repository. There are several backends used for testing. Google +also has its own cloud-based backend. There are also pluggable backends for storing other information than commits, such as the "operation store backend" for storing