The diff-editing code shares the `TreeState` functionality with the
working-copy code. That means we can now let the user edit conflicts
without materializing them first. So now the user can do e.g. `jj edit
-r <some commit>` and resolve only some of the conflicts.
As @arxanas noted, it's hard to tell which commit is currently checked
out. Hopefully bright colors will help. Maybe setting a background
color would be even clearer, but that's harder to do because the
formatter doesn't support background colors yet.
The CLI code for cloning a Git repo didn't use the usual
`finish_transaction()` method, because we didn't have support for
doing that on a repo that was creating half-way through a
command. That led to a bug where it would leave the initial checkout
(the one on top of the root commit) after checking out the correct
head.
`args` seems to make it clear that these are command-line arguments
(this is not Python, so there's no `*args`). It also avoids the risk
of conflicts and confusion with other matches (e.g. file patterns or
regexes).
Diffs between certain combinations of file types were not handled by
`jj diff` (for example, a diff between a conflict and another conflict
would not show a diff). This change fixes that, and also makes added
and removed files get printed with color and line numbers, which I've
often wanted.
The user currently has to edit `.jj/git/config` (or run `git
--git-dir=.jj/git config`) to manage remotes in the underlying Git
repo. That's not very discoverable (and we may change the path some
day), so let's provide a command for it.
As #33 says, the default diff we have can be hard to read and it
cannot be used for use with other tools. This patch adds a `jj diff
--git` mode for showing Git's flavor of unified diffs.
We should add a config option to get these diffs by default. For
interchange with other tools, we also need a way of turnning off color
codes in output (it's currently always on, even when when not printing
to a TTY).
It's been a lot of work, but now we're finally able to remove the
`Evolution` state! `jj obslog` still works as before (it just walks
the predecessor pointers).
This rewrites the `divergent` template keyword to be based on the
number of visible commits with a given change id. That's the same as
before; it's just that it's not based on the `Evolution` object's view
of which commits are visible anymore.
This is the last thing that depended on the evolution state!
Now that we no longer have to be careful whether we mean "all heads"
or "non-obsolete heads", there's no need to pass them as
arguments. It's still possible to get a DAG range to a hidden commit
by using `RevsetExpression::dag_range_to()`, as long as the hidden
commit is indexed.
Now that we remove hidden heads whenever a transaction commits,
`non_obsolete_heads()` should always be the same as `all_heads()`,
except during a transaction. I don't think we depend on the difference
even during a transaction. Let's simplify a bit by removing the revset
function `all_heads()` and renaming `non_obsolete_heads()` to
`heads()`. This is part of issue #32.
Branches and the working copy are currently updated to the parents of
the old commit (if they pointed to the old commit to start
with). That's not what's supposed to happen; they're supposed to be
updated to point to the new commit. This patch fixes that by manually
rebasing the immediate children of the old commit, so that
`MutRepo::create_descendant_rebaser()` will do the right thing.
This patch removes the `jj evolve` command, as part of removing the
evolution feature (#32). The command is very rarely useful since we
started evolving orphans after every transaction. I haven't used `jj
evolve` in many months.
After removing the command, the only good way of resolving divergence
will be `jj abandon` one side of the divergence. We will no longer
have a way of automatically merging the divergent commits. I plan to
add back that functionality, powered by the operation log instead of
the obsolescence log. That will probably take a long time, but it's
not a very high-priority feature anyway, so I think it's okay to lose
it for a while.
This is similar to how a recent change taught `DescendantRebaser` to
update branches pointing to rewritten commits. Now we also update the
checkout if it pointed to a rewritten commit.
This patch moves the logic for updating branches from
`update_branches_after_rewrite()` into `DescendantRebaser`. The
branches are now updated along with each rebased commit rather than
all being updated at the end. The new code uses the information about
rewritten and abandoned commits that `DescendantRebaser` gets from
`MutableRepo`. That is different from the old code, which used the
evolution state. This patch thus moves us one step closer to removing
evolution (#32).
I'm going to teach `DescendantRebaser` to also update local branches
pointing to rewritten commits, taking over the responsibility from
`rewrite::update_branches_after_rewrite()`. For commits that have been
rewritten as multiple new commits (divergent, not split), that
function makes local branches pointing to the old commit point to all
the new commits. To replicate that behavior in `DescendantRebaser`, it
needs to know about divergent changes. This change addresses that.
