Instead of calling `move_commits`, callers now have the option to call
`compute_move_commits` and then customize the rebase before calling
`ComputedMoveCommits::apply`. `ComputedMoveCommits::record_to_abandon`
can be used to abandon commits while rebasing.
The `Backend::read_file()` method is async but it returns a `Box<dyn
Read>` and reading from that trait is blocking. That's fine with the
local Git backend but it can be slow for remote backends. For example,
our backend at Google reads file chunks 1 MiB at a time from the
server. What that means is that reading lots of small files
concurrently works fine since the whole file contents are returned by
the first `Read::read()` call (it was fetched when
`Backend::read_file()` was issued). However, when reading files that
are larger than one chunk, we end up blocking on the next
`Read::read()` call. I haven't verified that this actually is a
problem at Google, but fixing this blocking is something we should do
eventually anyway.
This patch makes `Backend::read_file()` return a `Pin<Box<dyn
AsyncRead>>` instead, so implementations can be async in the read part
too.
Since `AsyncRead` is not yet standardized, we have to choose between
the one from `futures` and the one from `tokio`. I went with the one
from `tokio`. I picked that because an earlier version of this patch
used `tokio::fs` for some reads. Then I realized that doing that means
that we have to use a tokio runtime, meaning that we can't safely keep
our existing `pollster::FutureExt::block_on()` calls. If we start
depending on tokio's specific runtime, I think we would first want to
remove all the `block_on()` calls. I'll leave that for later. I think
at this point, we could equally well use `futures::io::AsyncRead`, but
I also don't know if there's a reason to prefer that.
This serves a similar purpose to Git's patch ID mechanism, however it is
slightly different in that it only compares commits which have the same
change ID as each other (divergent changes), and it does a full
comparison of the commits to see if they would have identical trees if
rebased onto the same parents. Since most changes aren't divergent, I
believe this should have a negligible performance cost in most cases.
I think skipping these commits by default makes sense for `jj rebase`,
since usually this will be a helpful behavior for the user. With this
behavior, a safe first step when encountering divergent changes would be
to rebase one branch on top of the other, since that will abandon any
divergent changes that have identical contents to existing commits,
leaving behind any non-trivial divergent changes for the user to resolve
manually.
`jj branch` has been deprecated since v0.22.0.
`renamed_cmd()` has no more callers now and has been removed. It can be added back in if
needed in the future.
The `jj branch` mentions in docs/design/tracking-branches.md have been left as they are
as a historical record since that document hasn't been updated since June 2024.
Since operation templates have "operation" label, commit templates should have
"commit" for consistency.
The [colors] table is not updated to use the "commit" prefix. There are some
non-template outputs which use unqualified "bookmark"/"tag"/"git_ref" labels.
That's also a reason why "bookmark_list" template doesn't have a "bookmark"
context label yet. (We'll need to qualify the color definition as "commit
bookmark" so the whole bookmark list wouldn't be colorized as "bookmark".)
I'm thinking of adding a top-level context label consistently. If we added
"commit" to the summary template (in code), the status output would be labeled
as "working_copy commit ..", whereas log entries would be labeled as "commit
working_copy ..". The latter should be more correct since the "commit" label
is global.
Now the working-copy entry is highlighted in op log and bookmark list, which
I think is good.
This assertion is redundant given both the `conflicts_with = "edit"` declaration on the
`no_edit` flag and the passing `test_edit_cannot_be_used_with_no_edit` test.
The `previous_op_id` doesn't belong to the operation immediately before the
`current_op_id`. There is one operation in between, namely the latest snapshot taken.
It isn't necessary to include shebangs in scripts passed into
`util exec` since you're already explicitly calling out the shell you'd
like to use. This change removes shebangs from examples for `util exec`
and adds a note below calling this out.
I'd like to make the internal `jj` binary at Google log the exit code,
but `ExitCode` doesn't seem to provide any way of getting the numeric
code out of it. This patch therefore replaces `ExitCode` by `u8` and
lets the `main()` function convert it to `ExitCode`. It's a bit
unfortunate but I don't see a better solution. It doesn't seem worth
it to create our own newtype for it.
This is just for completeness. I don't think this is practically useful, but the
:<format> syntax should work in both config files and command arguments.
Instead of saying to move configuration files from
`~/Library/Application Support` to `~/.config`, jj now tells you to move
configuration files from `~/Library/Application Support/jj` to
`~/.config/jj`.
The usage line originally showed `--from <REVSETS>|NAMES`, which was confusing as it
could be parsed as `--from (<REVSETS> or NAMES)`, rather than the correct `(--from
<REVSETS>) or NAMES`.
The order of the two arguments are now swapped, so that Clap displays it as
`NAMES|--from <REVSETS>` instead. Using bookmark names as the move targets should be
more common anyway. This is also consistent with the order in which the two arguments
are described in the command's doc comment.
This allows users to override the external tool set in ~/.jjconfig.toml. The
config variable is renamed to ui.diff-formatter to be consistent with the other
diff/merge editor settings.
--tool=:<format> support will be added separately.
Closes#3327
A divergent change could point to more than two commits, so the hint now suggests
abandoning unneeded commits rather than just one of them.
The `-r` flag is unnecessary for `jj abandon` as it is implied.
Also changed `<REVISION>` to `<commit_id>` to be clear that using the change id here
will not work.
This addresses part of #4414 and implements something akin to what's described in
@arxanas's [suggestion], with the exception that the editor contents don’t need to be
completely cleared, since whether cleared or not it is not obvious whether the user
intended to add an empty description or abort entirely.
[suggestion]: https://github.com/jj-vcs/jj/issues/4414#issuecomment-2359123535
The hint is not shown if an empty description is provided via `--message ""`, since the
user is explicitly bypassing the editor and wants to commit the change directly.
Otherwise, if a user exits the editor with an empty description (notwithstanding any
`JJ:` lines), it could be one of the following cases:
1. The user wants to commit the changes but no longer wants to add a description. The
hint can simply be ignored.
2. The user wants to commit the changes and add a description but accidentally exits the
editor. The second hint shows how to add a description to the parent commit.
3. The user no longer wants to commit the changes. However, a new commit is still
created to maintain consistent behaviour as when an empty description is provided via
the CLI. The first hint shows how to undo the commit.
