mirror of
https://github.com/martinvonz/jj.git
synced 2025-05-05 15:32:49 +00:00
doc: update some references to "the native backend"
This commit is contained in:
parent
ca616fade2
commit
be0ad55309
@ -212,17 +212,12 @@ the header of the website when you scroll to the top of any page.
|
|||||||
### Compatible with Git
|
### Compatible with Git
|
||||||
|
|
||||||
Jujutsu is designed so that the underlying data and storage model is abstract.
|
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,
|
Today, only the Git backend is production-ready. The Git backend uses the
|
||||||
while the other is a native storage backend[^native-backend]. The Git backend
|
[libgit2](https://libgit2.org/) C library and the
|
||||||
uses the [libgit2](https://libgit2.org/) C library and the
|
|
||||||
[gitoxide](https://github.com/Byron/gitoxide) Rust library.
|
[gitoxide](https://github.com/Byron/gitoxide) Rust library.
|
||||||
|
|
||||||
[backends]: https://jj-vcs.github.io/jj/latest/glossary#backend
|
[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
|
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.
|
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
|
You can fetch branches from a regular Git remote and push branches to the
|
||||||
|
@ -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
|
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
|
internal Mercurial. Currently git-branchless `git test` and `hg fix` implement
|
||||||
some kind of command runner. The Google internal `hg run` works in
|
some kind of command runner. The Google internal `hg run` works in conjunction
|
||||||
conjunction with CitC (Clients in the Cloud) which allows it to lazily apply
|
with CitC (Clients in the Cloud) which allows it to lazily apply the current
|
||||||
the current command to any affected file. Currently no Jujutsu backend
|
command to any affected file. Currently no open-source Jujutsu backend (Git,
|
||||||
(Git, Native) has a fancy virtual filesystem supporting it, so we
|
Simple) has a fancy virtual filesystem supporting it, so we can't apply this
|
||||||
can't apply this optimization. We could do the same once we have an
|
optimization. We could do the same once we have an implementation of the working
|
||||||
implementation of the working copy based on a virtual file system. Until then,
|
copy based on a virtual file system. Until then, we have to run the commands in
|
||||||
we have to run the commands in regular local-disk working copies.
|
regular local-disk working copies.
|
||||||
|
|
||||||
## Goals and Non-Goals
|
## Goals and Non-Goals
|
||||||
|
|
||||||
|
@ -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
|
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
|
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
|
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.
|
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.
|
Jujutsu, you'll need to go through this process.
|
||||||
|
|
||||||
## Process
|
## Process
|
||||||
|
@ -10,11 +10,10 @@ stores a list of [heads](#head) of such branches.
|
|||||||
|
|
||||||
## Backend
|
## Backend
|
||||||
|
|
||||||
A backend is an implementation of the storage layer. There are currently two
|
A backend is an implementation of the storage layer. There is currently only one
|
||||||
builtin commit backends: the Git backend and the native backend. The Git backend
|
production-ready builtin commit backend: the Git backend. The Git backend stores
|
||||||
stores commits in a Git repository. The native backend is used for testing
|
commits in a Git repository. There are several backends used for testing. Google
|
||||||
purposes only. Alternative backends could be used, for example, if somebody
|
also has its own cloud-based backend.
|
||||||
wanted to use jj with a humongous monorepo (as Google does).
|
|
||||||
|
|
||||||
There are also pluggable backends for storing other information than commits,
|
There are also pluggable backends for storing other information than commits,
|
||||||
such as the "operation store backend" for storing
|
such as the "operation store backend" for storing
|
||||||
|
Loading…
x
Reference in New Issue
Block a user