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).
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).
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`.
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).
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.
This makes it so that almost every command will remove non-visible
heads. That shouldn't have much visible effect, except that the
`all_heads()` revset will become the same as
`non_obsolete_heads()`.
It will help us remove support for evolution by cleaning up existing
repos. Existing repos (like mine) will lose the unwanted heads (~8.5k
heads in my case), so they don't clutter the repo once evolution is
gone.
This is part of issue #32.
This change makes it so `jj abandon` uses `DescendantRebaser` for
rebasing descendants of the abandoned commits. That makes it not
depend on evolution for it.
Descendants of abandoned commits should be rebased onto their parents,
or the rewritten parents if they had been rewritten. This patch
teaches `DescendantRebaser` to do that. It updates `jj rebase -r` to
use the functionality. I plan to also use it in `jj abandon`
(naturally, given the name), and for rebasing descendants of deleted
refs imported from `jj git refresh/fetch/push`.
The command's help text says "Abandon a revision", which I think is a
good indication that the command's name should be `abandon`. This
patch renames the command and other user-facing occurrences of the
word. The remaining occurrences should be removed when I remove
support for evolution.
This makes conflicted branches pointing to the working copy get
updated when the working copy changes, just like they are when it
changes for other reason (such as `jj describe`).
This patch moves the function for updating branches after rewrite from
`commands.rs` into `rewrite.rs`.
It also changes the function to update branches even if they were
conflicted or become conflicted. I think that seems better than
leaving branches on old commits. For example, let's say you have start
with this:
```
C main
|
B origin@main
|
A
```
You now pull from origin, which has updated the main branch from B to
B'. We apply that change to both the remote branch and the local
branch, which results in a conflict in the local branch:
```
C main?
|
B B' main? origin@main
|/
A
```
If you now rewrite C to C', the conflicted main branch will still
point to C, which is just weird. This patch changes that so the
conflicted side of main gets repointed to C'.
I also refactored the code to reuse our existing
`MutableRepo::merge_single_ref()`, which improves the behavior in
several cases, such as the conflict-resolution case in the last test
case.
I don't know why I hadn't already updated these. Maybe I thought it
wasn't necessary. That's probably true right now, but I want to make
`jj git fetch` and `jj git refresh` automatically rebase commits when
branches were updated on a remote or in the underlying Git repo. We
want to make sure that the working copy also gets updated then.
I forgot to remove the `fetch_head` from a variable name when I
recently realized that Git's `FETCH_HEAD` is not what we want to check
out after fetching.
It turns out that `FETCH_HEAD` is not the remote's `HEAD` (it's
actually not even a normal symbolic ref; it contains many lines of
commits and names). We're supposed to ask the remote for its default
branch instead. That's what this patch does.
It's annoying to have to add `--branch main` every time I push to
GitHub.
Maybe we should make it push only the current branch by default, but
we don't even have a concept of a current branch yet...
