For the same reason as the previous commit.
Created and moved stats are printed separately because it's unusual to do both
within one "branch set" invocation.
For the same reason as cdc0cc360162. This will help notice problems like wrong
target revision.
The warning for multiple branches is reorganized as a hint for "-r" option,
which I think is the main purpose of this warning. Unlike "squash", we don't
check if an argument can be parsed as a revset because branch name is usually
a valid symbol expression.
The output looks somewhat similar to color-words diffs. Unified diffs are
verbose, but are easier to follow if adjacent lines are added/removed + modified
for example.
Word-level diffing is forcibly enabled. We can also add a config knob (or
!color condition) to turn it off to save CPU time.
I originally considered disabling highlights in block insertion/deletion, but
that wasn't always great. This can be addressed separately as it also applies
to color-words diffs. #3958
Forgetting a workspace removes its working-copy commit, so it makes
sense for it to be abandoned if it is discardable just like editing a
new commit will cause the old commit to be abandoned if it is
discardable.
It's nice to see the result of "branch move", "create", etc., and this is more
important in "branch move" because the source branches can be specified in an
abstracted way. I originally considered printing a list of affected branches,
but it looked rather verbose. Since the destination revision is unique, we can
use commit_summary template instead.
This patch also removes a warning about multiple branches because the branch
names are included in the commit summary. I think the hint message is good
enough to signal possible mistake.
We usually print stats at the end of mutable operation, and I think these
messages are useful even if N = 1. I understand that "Deleted N" (N > 1) is
unusual and the original intent of these messages was to signal possible
mistakes. However, I don't think printing N=1 stats would nullify the original
purpose.
No emptiness check is needed for delete/forget, but names can be empty in
track/untrack because of noop changes.
The last hunk could be truncated instead, but the .peekable() version is easier
to follow. If we truncated lines, we would have to adjust line ranges
accordingly.
show_context_after was set once when DiffHunk::Different received, and was
never turned off. This means DiffHunk::Matching is not supposed to repeat.
Under this condition, we can assume that removed/added lines exist if lines
isn't empty.
At work, a user encountered a panic upon attempting to create a dir at
the line in the diff below, but it turned out to be difficult to debug
because I didn't know what the path was. There already is a mechanism to
add path context in the lib crate; make it available in the cli crate as
well, and use the mechanism to add path context to "workspace add".
Now, the command for `jj git remote add` is `cmd_git_remote_add` and its
argument type is `GitRemoteAddArgs`. This should make it easier to find
the CLI docs and the implementation for commands.
This is how `jj branch` commands were already set up in this way. The
`jj op` commands were also already set up in this way, except the
functions are called e.g. `cmd_op_undo`, I kept this for simplicity.
I was mainly motivated by the `jj file` commands. Most other commands
had functions already named in the above pattern, but used to have
shorter argument type names.
We have two other kinds of working copies at Google and it's sometimes
useful to get the basic information about operation id and tree id for
them, for exampel for debugging stale workspaces. This patch adds a
command for that.
We could instead have made the old `jj debug working-copy` command
work for all kinds of working copies (like the new command) and only
have extra information for the standard local-disk implementation. I
don't feel strongly either way and could do it other other way instead
if people prefer that.
While explaining branch tracking behavior, I find it's bad UX that a deleted
branch can be re-"create"d with tracking state preserved. It's rather a "set"
operation. Since deleted tracking branch is still listed, I think it's better
to assume that the local branch name is reserved.
https://github.com/martinvonz/jj/discussions/3871
Renaming to deleted tracking branch is still allowed (with warning) because the
"rename" command can't handle tracked remotes very well. If it were banned, bad
rename couldn't be reverted by using "jj branch rename". It would be confusing
if "rename a b" succeeded with warning, but the following "rename b a" failed.
This will help inline view.remove_branch() in cmd_branch_forget(). I don't
care much about owned (String, _) vs (&str, _), but we can't simplify the
lifetime issue in find_forgettable_branches() anyway. So I made all callers
pass cloned Arc<ReadonlyRepo> and borrow (name, target) pairs from there.
We now have two `cmd_show` in the repo. I think this one should become
`cmd_file_show`, but this should be done uniformly over all the commands
for consistency.
I did *not* keep `print` as an alias (I couldn't find a compelling
reason to do it), but let me know if anyone feels like keeping it.
We don't want e.g. `jj diff --git` to have underlined text because
it's redundant there. This patch fixes that by adding a new `token`
label used only in the color-words diff (for now - it may be used in
git diffs in the future).
This means we could remove the `line_number` label but I left it
because there's little harm in having it and it seems like it can
still be useful.
Thanks to @yuja for noticing and suggesting the fix.
If you want to set a background color on added/removed lines, you
currently get the same style on the line numbers. This patch lets you
specify a different style by overriding it on the line numbers.
