This not only makes the output easier to read, but also protects against
implementation detail changes in `write!` when used with a format
string (especially, how many times and with what strings it calls the
underlying writer).
Partially resolve a 1.5‐year‐old TODO comment.
Add opt‐in syntax for case‐insensitive matching, suffixing the
pattern kind with `-i`. Not every context supports case‐insensitive
patterns (e.g. Git branch fetch settings). It may make sense to make
this the default in at least some contexts (e.g. the commit signature
and description revsets), but it would require some thought to avoid
more confusing context‐sensitivity.
Make `mine()` match case‐insensitively unconditionally, since email
addresses are conventionally case‐insensitive and it doesn’t take
a pattern anyway.
This currently only handles ASCII case folding, due to the complexities
of case‐insensitive Unicode comparison and the `glob` crate’s lack
of support for it. This is unlikely to matter for email addresses,
which very rarely contain non‐ASCII characters, but is unfortunate
for names and descriptions. However, the current matching behaviour is
already seriously deficient for non‐ASCII text due to the lack of any
normalization, so this hopefully shouldn’t be a blocker to adding the
interface. An expository comment has been left in the code for anyone
who wants to try and address this (perhaps a future version of myself).
`tx.format_commit_summary()` can be expensive because it needs to build
an IdPrefixContext now, so it's best to avoid formatting instruction
messages unless they are actually required.
Patience diff starts by lining up unique elements (e.g. lines) to find
matching segments of the inputs. After that, it refines the
non-matching segments by repeating the process. Histogram expands on
that by not just considering unique elements but by continuing with
elements of count 2, then 3, etc.
Before this commit, when diffing "a b a b b" against "a b a b a b", we
would match the two "a"s in the first input against the first two "a"s
in the second input. After this patch, we ignore the "a"s because
their counts differ, so we try to align the "b"s instead.
I have had this commit lying around since I wrote the histogram diff
implementation in 1e657c5331. I vaguely remember thinking that the
way I had implemented it (without this commit) was a bit weird, but I
wasn't sure if this commit would be an improvement or not. The bug
report from @chooglen today of a case where we behave differently from
Git is enough to make me think that we make this change after all.
#761
I've run into change ID prefixes being 4-5 characters instead of the
usual 1-2 characters in commands like `jj duplicate` and `jj split`
fairly often, and it seems like this should resolve that.
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 cdc0cc3601. 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".
It's common to create empty working-copy commits while using jj, and
currently the author timestamp for a commit is only set when it is first
created. If you create an empty commit, then don't work on a repo for a
few days, and then start working on a new feature without abandoning the
working-copy commit, the author timestamp will remain as the time the
commit was created rather than being updated to the time that work began
or finished.
This commit changes the behavior so that discardable commits (empty
commits with no description) by the current user have their author
timestamps reset when they are rewritten, meaning that the author
timestamp will become finalized whenever a commit is given a description
or becomes non-empty.
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.
