Intersection of unchanged ranges becomes a simple merge-join loop, so I've
removed the existing tests. I also added a fast path for the common 2-way
diffs in which we don't have to build vec![(pos, vec![pos])].
One source of confusion introduced by this change is that WordPosition means
both global and local indices. This is covered by the added tests, but I might
add separate local/global types later.
It's silly that we build new Vec for each recursion stack and merge elements
back. I don't see a measurable performance difference in the diff bench, but
this change will help simplify the next patch. If a result vec were created for
each unchanged_ranges() invocation, it would probably make more sense to return
a list of "local" word positions. Then, callers would have to translate the
returned positions to the caller's local positions.
When `format_short_signature(signature)` is set to `signature.name()` the author names are not yellow like other signature types (eg email and username). When the commit signatures have no colors, they blend in making it hard to distinguish between signatures and commit messages.
If just `name` were set to `yellow`, just like email and username, it affects the colorization of branch names making them also yellow despite them being designated as magenta. Setting `author` and `committer` to `yellow` is specific enough to allow branches to keep their colors while still coloring signature names. This is known to affect signatures in both 'log' and 'show'.
We can assign a unique integer to each (word, occurrence) pair instead. As a
bonus, HashMap can be replaced with Vec.
```
group new old
----- --- ---
bench_diff_git_git_read_tree_c 1.00 72.5±3.25µs 1.08 78.5±0.48µs
bench_diff_lines/modified/10k 1.00 45.1±1.18ms 1.10 49.8±1.85ms
bench_diff_lines/modified/1k 1.00 4.1±0.07ms 1.11 4.5±0.34ms
bench_diff_lines/reversed/10k 1.00 19.0±0.12ms 1.12 21.2±1.26ms
bench_diff_lines/reversed/1k 1.00 558.5±37.42µs 1.17 655.6±16.27µs
bench_diff_lines/unchanged/10k 1.00 5.3±0.78ms 1.33 7.0±0.89ms
bench_diff_lines/unchanged/1k 1.00 422.0±16.68µs 1.28 540.7±13.96µs
```
Let the user select all changes interactively and put them into
the first commit, and create a second commit with the possibility
of preserving the current commit message. This was previously only
possible in non-interactive mode by specifying matching paths, e.g.
".". In both cases, a warning will be issued indicating that the second
commit is empty.
jj split warning was potentially wrong in both interactive and
non-interactive modes when everything is put into the child commit:
- Non-interactive mode: "The given paths does not match any file:
PATHS". The message is misleading, as the PATHS given on the command-line
may match files but not match files containing changes.
- Interactive mode: "The given paths does not match any file: " while
if possible that no paths were given on the command line.
Move this update under `Unreleased`. I started the change before the last
release and after rebasing, forgot to move it. Fixing it now thanks to @yuja
catching this on time.
Issue: #4122
I'll add a few more helper methods there. It might also make sense to cache
precomputed hash values.
unchanged_ranges() is made private since there are no external callers, and
I'm going to add more private types.
See discussion thread in linked issue.
With this PR, all revset functions in [BUILTIN_FUNCTION_MAP](8d166c7642/lib/src/revset.rs (L570))
that return multiple values are either named in plural or the naming is hard to misunderstand (e.g. `reachable`)
Fixes: #4122
Stacking at AliasExpanded node looks wonky. If we migrate error handling to
Diagnostics API, it might make sense to remove AliasExpanded node and add
node.aliases: vec![(id, span), ..] field instead.
Some closure arguments are inlined in order to help type inference.
* See #4239 for details.
* For now, update working copy before reporting repo changes, so that
potential errors in reporting changes don't leave the repo in a stale
state.
Fixes: #4239
* First fetch from remote.
* Then check tx.{base_repo(),repo}.view().remote_bookmarks_matching(<branch>, <remote>).
This has to happen after the fetch has been done so the tx.repo() is updated.
* Warn if a branch is not found in any of the remotes used in the fetch. Note that the remotes
used in the fetch can be a subset of the remotes configured for the repo, so the language
of the warning tries to point that out.
Fixes: #4293
I recently got random test_commit_parallel*() failures, and this patch appears
to fix the problem.
SimpleOpHeadsStore::update_op_heads() adds new_id file and removes old_ids
files in that order. It ensures that there exists at least one id file, but it
doesn't mean readdir() can observe the added id file.
1. process A: get_op_heads() -> opendir()
2. process B: update_op_heads() -> add_op_head(new_id), remove_op_head(old_id)
3. process A: -> readdir() (can miss new_id)
update_op_heads() could do rename(old_ids[0], new_id), but I don't remember if
readdir() can always pick up a renamed entry.
