--at-op should be invalid on repo initialization. "init --ignore-working-copy"
could be supported by using working_copy.reset(), but I don't think it's
worth the effort. If the working directory is empty, --ignore-working-copy
is meaningless, and if the directory is not empty, the user would probably
want to do snapshot at some point.
I'm going to fix misuse of CommandHelper::for_loaded_repo(), which expects
that the given repo respects the --at-operation option.
I don't think all of the added tests are useful, but "clone
--ignore-working-copy" might be legit as a replacement for bare repos.
The user can define the setting `git.private-commits` as they desire. For
example:
git.private-commits = 'description(glob:"wip:*")'
If any commits are in this revset, then the push is aborted.
If a commit would be private but already exists on the remote, then it does
not block pushes, nor do its descendents block pushes unless they are also
contained in `git.private-commits`.
Closes#3376
The user probably would expect the path to be relative to their current
directory rather than the workspace root. For instance, if the user is
in a child directory and runs `jj workspace add ../../name`, then they
might be surprised if we printed "../name" instead of "../../name".
Prevents a warning from being printed when renaming branches in a
colocated repo, since git tracking branches were being considered as
remote tracking branches.
It's inconvenient that we have to quote glob patterns as 'glob:"*.rs"'. Suppose
filesets are usually specified in shell, it's better to allow unquoted strings
if possible. This change also means we'll probably abandon #2101 "make the
parsing of string arguments stricter."
Note that we can no longer introduce ? operator or [] subscript syntax in
filesets.
Closes#4053
This patch adds TreeDiff template type to host formatting options. The main
reason of this API design is that diff formats have various incompatible
parameters, so a single .diff(files, format[, options..]) method would become
messy pretty quickly. Another reason is that we can probably add custom
summary templating support as diff.files().map(|file| file.path()..).
RepoPathUiConverter is passed to templater explicitly because the one stored
in RevsetParseContext is behind Option<_>.
Since fileset and revset languages are syntactically close, we can reparse
revset expression as a fileset. This might sound a bit scary, but helps
eliminate nested quoting like file("~glob:'*.rs'"). One oddity exists in alias
substitution, though. Another possible problem is that we'll need to add fake
operator parsing rules if we introduce incompatibility in fileset, or want to
embed revset expressions in a fileset.
Since "file(x, y)" is equivalent to "file(x|y)", the former will be deprecated.
I'll probably add a mechanism to collect warnings during parsing.
Currently, when there is a commit with two predecessors, the graph
splits into two branches, and all of the predecessors on the first
branch are printed before all of the predecessors on the second branch.
This causes the graph to grow wider with each squashed commit, since the
second branch must always get indented one level farther each time a
commit is squashed. I have some commits where the graph is indented more
than 10 levels due to squashing more than 10 times, making it very
difficult to read.
Reversing the order and printing the second branch before the first
branch prevents this unnecessary indentation and makes the graph easier
to read. This does not change the order of the edges in the graph (i.e.
the first predecessor is still the first edge and the second predecessor
is still the second edge in the graph).
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).
`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.
