cybercyst/jj
1
0
Fork 0
mirror of https://github.com/martinvonz/jj.git synced 2025-05-05 07:22:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

doc: update some references to "the native backend"

Browse Source
This commit is contained in:
Martin von Zweigbergk 2025-03-21 08:47:50 -07:00
parent ca616fade2
commit be0ad55309
4 changed files with 15 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
README.md
View File

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

14
docs/design/run.md
View File

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

4
docs/design_docs.md
View File

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

9
docs/glossary.md
View File

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