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.
The auto-rebasing of descendants doesn't work if you have an open
commit checked out, which means that you may still end up with orphans
in that case (though that's usually a short-lived problem since they
get rebased when you close the commit). I'm also about to make
branches update to successors, but that also doesn't work when the
branch is on a working copy commit that gets rewritten. To fix this
problem, I've decided to let the caller of `WorkingCopy::commit()`
responsible for the transaction.
I expect that some of the code that this change moves from the lib
crate to the cli crate will later move back into the lib crate in some
form.
I want to reuse this bit of code for evolving descendants of a
rewritten working copy commit.
I expect this to change again soon (I'll probably make it do a regular
rebase instead of evolve), but this will do for now.
This makes it so (local) branches get updated when the commit they
point to gets rewritten. If the branch was conflicted, we just print a
warning and don't update the branch (though one could imagine
rewriting the conflict). We also just print a warning if the new
target is unclear because the commit was rewritten into multiple new
commits (divergent).
The updating doesn't work when the working copy commit gets rewritten
because the working copy changed on disk. That's because that's done
in a separate transaction inside `working_copy.rs`. That's similar to
how orphans of the working copy commit don't get automatically
evolved. I'll fix both problems soon.
With this change, we no longer fail if the user moves a branch
sideways or backwards and then push.
The push should ideally only succeed if the remote branch is where we
thought it was (like `git push --force-with-lease`), but that requires
rust-lang/git2-rs#733 to be fixed first.
Now that we have native branches, we can make `jj git push` only be
about pushing a branch to a remote branch with the same name.
We may want to add back support for the more advanced case of pushing
an arbitrary commit to an arbitrary branch later, but let's get the
common case simplified first.
I had forgotten to make the `delete` argument a flag by giving it a
name, so instead it conflicted with `name` argument, as tests
discovered.
While at it, I also made `name` required. It wasn't before because I
originally had a single command for `jj branch` and `jj branches` and
then I didn't think to make it required when I split them up.
Now that our own branches and tags are updated when git refs are
updated and the user can use them to specify revisions, we can start
displaying them instead of the git refs. This commit adds new
`branches` and `tags` template keywords and updates the default
templates to use them instead of `git_refs`.
The new `diff::DiffHunk` type is very similar but more generic. We
don't need the generality here. I just don't two very similar types
with the same name.
This change teaches `Tree::diff()` to filter by a matcher. It only
filters the result so far; it does not restrict the tree walk to what
`Matcher::visit()` says is necessary yet. It also doesn't teach the
CLI to create a matcher and pass it in.
This patch makes it so we use color in the graph iff we use it other
output. We currently always use color except for in the smoke tests,
so it has no effect in practice. It's easy to turn off color when
stdout is redirected (using the `atty` crate), but I haven't done that
because I occasionally pipe `jj log` output to `less` and I want color
then.
This both helps find the current checkout and head operation and
hopefully helps teach the user that "@" is the symbol for the working
copy. I removed the current "<--" indication from the graph (and
non-graph) log template. Hopefully the "@" is clear enough on its own,
but we may want to add back some further indication later. We'll see.
I considered even changing the message to "Checking out: <commit>" as
that's technically more correct (the message is printed when the
view's checkout is updated, i.e. before the working copy is
updated). However, I worried that users would find it confusing that
e.g. `jj close` would result in a "Checking out: " message, even
though that's what actually happens.
I remember adding that message a long time ago so the user has a trace
of working copy commit ids in the terminal output. They should be able
to get the same information from the operation log combined with
e.g. `jj st --at-op`.
We already support using "@" to refer to the head operation when doing
e.g. `jj op undo -o @`. This patch adds support for `--at-op=@`. It
also makes that the default.
This prepares `jj status` for working better on an old repo state
(with `--at-op`). When looking at an old repo state, the "working
copy" should reflect the state from that state, i.e. the view's
"checkout", not the current working copy.
Before this patch, `jj log` would always commit the working copy and
most other commands would commit the working copy only if they were
passed a revset of exactly "@". This patch makes it so they all commit
the working copy unless they are passed just a symbol other than "@"
(typically a commit id). That means that we will not commit the
working copy if the user does `jj diff -r abc123`, but we will if they
do `jj diff -r :abc123`. It's clearly unnecessary in both those cases,
and we should fix, but this is probably good enough for now.
