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.
With this change, you can do e.g. `heads(remote_branches())`. That
should currently be the same as `public_heads()`, except that we don't
yet remove public heads when remote branches have been updated. Having
this support should be generally useful, but I may use it in the short
term specifically for depending less on the public heads, until I get
around to keeping them up to date.
I also changed the instructions to use `cargo install --git` pointing
straight to GitHub, so we don't have the naming conflict with the jj
repo created in the tutorial.
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).
I noticed while working on support for unified diffs (#33) that
`Diff::for_tokenizer(..., &find_line_ranges)` would return a
`DiffHunk::Matching` for each matching line instead of a single
`DiffHunk::Matching` for all the matching lines. That's different from
what you get from `Diff::default_refinement()` and seems less
convenient to work with.
My SSH keys are password-protected, so I haven't been able to test
this patch completely, but I believe it should work. We now use
ssh-agent if `$SSH_AGENT_PID` is set, otherwise we check if
`$HOME/.ssh/id_rsa` exists and assume it's a password-less key. That's
quite hacky but I think it's good enough for now. We eventually need
to move this out of the library crate just like libgit2 has done.
Closes#25.
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!
The removal of hidden heads was just there to help with the transition
away from evolution (#32). Now that we no longer depend on evolution
for removing old heads, we can remove the hack.
This rewrites the code for resolving a change id to simply walk the
entire index. That's obviously not optimal, but it's not worse than
what we did in the evolution-based resolution. This is yet another
step towards removing support for evolution (#32).
This patch teaches `DescendantRebaser` to also update heads. That's
done at the end of the rebase (when `rebase_next()` starts returning
`None`), which is a little weird. We should probably change the
interface, but this will do for now.
With this change, we should no longer need to remove hidden heads when
the transaction commits. That will remove one of the last bits of
dependence on evolution from most commands (#32).
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.
I recently made the CLI remove hidden heads when a transaction is
committed (38474a9). Let's move that to `Transaction::commit()`, so
the library crate becomes more similar to how the CLI behaves and more
similar to our evolution-less future (#32).
The next patch would otherwise make this test fail because
"transaction 2" tries to point a branch to a commit that's not visible
(because it's created by the concurrent "transaction 1").
This makes `jj rebase` and `jj abandon` rebase descendants using
`MutableRepo::create_descendant_rebaser()`, except that `jj rebase -r`
needs to be special-case since it doesn't rebase descendants onto the
rewritten commit.
This change makes it so we rebase descendants based on the rewrite
information recorded in `MutableRepo` instead of using evolution for
it. This is an important step towards removing evolution (#32).
When we remove evolution (#32), I don't intend to replicate the hack
it had for rebasing descendants onto a split commit. Let's instead
have `jj split` manually rebase descendants of the original commit
onto the second part of the split. We use `DescendantRebaser` for
that. Branches and the working copy pointing to the split commit are
still updated using evolution in
`RepoCommandHelper::finish_transaction()`. I plan to have
`DescendantRebaser` update branches and working copies as well. That
should then also work as expected for `jj split`.
Same reasoning as the previous change.
With this change, I believe we now record all rewritten and abandoned
commits correctly. We're now almost ready to switch the CLI away from
using evolution for automatically rebasing commits.
This change makes `jj squash` and `jj unsquash` record the child or
parent (respectively) as abandoned if it becomes empty. We need to do
that because it won't get automatically recorded by
`CommitBuilder`. We could make `CommitBuilder` record abandoned
commits when `set_pruned()` was called, but that would be
short-sighted since we're about to delete that function as part of
removing support for evolution (#32).
This is part of removing support for evolution (#32). Since
`CommitBuilder` now records rewritten commits in `MutableRepo`, we can
use that recorded information to automatically rebase descendants.
When we remove support for evolution (#32), we need to still make it
easy for application code to rebase descendants of rewritten and
abandoned commits. The way applications currently do that is by using
e.g. `CommitBuilder::for_rewrite_from()` followed by
`evolve_orphans()`. This patch puts some bookkeeping in `MutableRepo`
for rewritten and abandoned commits, along with a function for
creating a `DescendantRebaser` based on it. I'll then make
`CommitBuilder` record rewritten commits there.
After writing a new working copy commit, we update branches pointing
to it, and we rebase descendants on top. However, we should be doing
that in the opposite order, so the branch updates apply to rewritten
descendants as well.
