ok/jj
1
0
Fork 0
forked from mirrors/jj
Code Pull requests Activity

docs: start describing differences compared to Git

Browse source 
I've surely missed a lot here, but one has to start somewhere.
This commit is contained in:
Martin von Zweigbergk 2022-03-11 12:58:50 -08:00 committed by Martin von Zweigbergk
parent 05734138e8
commit 6902c703b3
1 changed files with 50 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

51
docs/git-comparison.md
View file

@ -1,6 +1,55 @@
# Comparison with Git
TODO: Describe the differences compared to Git here
## Introduction
This document attempts to describe how Jujutsu is different from Git. See
[the Git-compatibility doc](git-compatibility.md) for information about how
the `jj` command interoperates with Git repos.
## Overview
Here is a list of conceptual differences between Jujutsu and Git, along with
links to more details where applicable and available. There's a
[table further down](#command-equivalence-table) explaining how to achieve
various use cases.
* **The working copy is automatically committed.** That results in a simpler and
more consistent CLI because the working copy is now treated like any other
commit. [Details](working-copy.md).
* **There's no index (staging area).** That also results in a simpler
CLI for similar reasons. The index is very similar to an intermediate commit
between `HEAD` and the working copy, so workflows that depend on it can be
modeled using proper commits instead. [Details](#the-index).
* **No need for branch names.** Git lets you check out a commit without
attaching a branch. It calls this state "detached HEAD". This is the normal
state in Jujutsu (there's actually no way -- yet, at least -- to have an
active branch). However, Jujutsu keeps track of all visible heads (leaves) of
the commit graph, so the commits won't get lost or garbage-collected.
* **Conflicts can be committed.** No commands fail because of merge conflicts.
The conflicts are instead recorded in commits and you can resolve them later.
[Details](conflicts.md).
* **Descendant commits are automatically rebased.** Whenever you rewrite a
commit (e.g. by running `jj rebase`), all its descendants commits will
automatically be rebased on top. Branches pointing to it will also get
updated, and so will the working copy if it points to any of the rebased
commits.
* **Branches are identified by their names (across remotes).** For example, if
you pull from a remote that has a `main` branch, you'll get a branch by that
name in your local repo as well. If you then move it and push back to the
remote, the `main` branch on the remote will be updated.
[Details](branches.md).
* **The operation log replaces reflogs.** The operation log is similar to
reflogs, but is much more powerful. It keeps track of atomic updates to all
refs at once (Jujutsu thus improves on Git's per-ref history much in the same
way that Subversion improved on RCS's per-file history). The operation log
powers e.g. the undo functionality. [Details](operation-log.md)
* **There's a single, virtual root commit.** Like Mercurial, Jujutsu has a
virtual commit (with a hash consisting of only zeros) called the "root commit"
(called the "null revision" in Mercurial). This commit is a common ancestor of
all commits. That removes the awkward state Git calls the "unborn branch"
state (which is the state a newly initialized Git repo is in), and related
command-line flags (e.g. `git rebase --root`, `git checkout --orphan`).
## The index