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...
I'm not sure what the interface should be, but until public heads are
automatically removed when they disappear from a remote, this will at
least be useful as a workaround.
For example:
```
main: 4f2efc5bb873 cli: make `jj branches` say how much remote branches are ahead/behind
@origin (behind by 2 commits): 5023d8d360 Merge pull request #26 from martinvonz/git-comparison
```
It turns out that `--help` provides a longer version of the help text
than `-h` does. I only discovered that because I was wondering what
the difference between `clap::App::about()` and
`clap::App::long_about()` was. There's clap-rs/clap#1015 for tracking
it in clap, but let's clarify it ourselves for now by changing the
help text for `-h/--help`.
With this commit, you can run `jj concepts branches` to get help about
the "branches" concept. We don't have much help for other commands and
their arguments yet, but I'm starting with concept guides so we can
point to them as we add help for commands and their arguments.
I initially tried to make the command to get help be `jj help
--concept branches`. That would require replacing clap's
implementation of the help command with our own. clap-rs/clap#1350
prevented me from doing that. But I'm pretty happy with having it
under `jj concepts` anyway. It's probably more discoverable that way.
I tried to mimic clap's styling with yellow headings.
Clap uses present tense by default (e.g. "Prints help information"). I
considered switching our message to that style, but I found it harder
to describe some flags that way.
I think it makes sense to have a version of rebase that rebases the
descendants of the rebased commit onto the parents of the rebased
commit. Let's make `jj rebase -r` do just that. Let's also add `jj
rebase -s` (matching Mercurial's `hg rebase -s`) for rebasing a commit
and its descendants onto another commit.
Since both flavors of the command now explicitly rebase the
descendants (just to different destinations), I also made the command
not evolve orphans afterwards. That would have made sense regardless
of this commit.
This change makes `jj status` include a section about conflicted local
branches and another section about conflicted remote branches. They
show up only if there are conflicts. They include hints about how to
resolve.
