docs: start describing differences compared to Git
I've surely missed a lot here, but one has to start somewhere.
# 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
