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.
Deprecation warnings will be printed there. auto_tracking_matcher(ui) could
be cached, but there aren't many callers right now, so it should be okay to
parse and emit warnings for each invocation. Other than that, the changes are
straightforward.
I'll make parse_<language>_template() require &Ui, but these cached templates
should be re-constructible without access to a Ui.
Maybe we can split a parsed template object into RevsetExpression-like
evaluation tree and interpreter environment, but that'll be a big challenge.
This will help simplify warning handling in future patches. I'm going to add
deprecation warnings to revset, so Ui will be required in order to parse a user
revset expression.
revset_util::parse_immutable_expression() is inlined as it's a thin wrapper
around parse_immutable_heads_expression().
I'm testing simple conflicts diffs locally, and we'll probably need to handle
consecutive context hunks when we add some form of unmaterialized conflicts
diffs. Let's buffer context hunks (up to 1 right now.) The new code looks
simpler.
`jj bookmark` is a frequently used command. Its subcommands already have
one letter aliases. Defining `jj b` as an alias for `jj bookmarks` make
bookmarks really easy to use.
I think it's slightly easier to follow if we calculate a diff of input bits
first. I don't know which one is faster, but I assume compiler can optimize to
similar instructions.
Comparing each byte before comparing the nibbles is more efficient. A
benchmark comparing the old and new implementations with various common
prefix lengths shows:
```
Common hex len/old/3 time: [7.5444 ns 7.5807 ns 7.6140 ns]
Common hex len/new/3 time: [1.2100 ns 1.2144 ns 1.2192 ns]
Common hex len/old/6 time: [11.849 ns 11.879 ns 11.910 ns]
Common hex len/new/6 time: [1.9950 ns 2.0046 ns 2.0156 ns]
Common hex len/old/32 time: [63.030 ns 63.345 ns 63.718 ns]
Common hex len/new/32 time: [6.4647 ns 6.4800 ns 6.4999 ns]
```
"Bookmark changes" sounds like changes will be bookmarked, and "Bookmark" here
is redundant. If we add support for pushing tags, this message will have to be
generalized anyway.
This makes it easier to work with multiple remotes at once while
tracking the default branch of the remote used to create the local
repository:
```shell
$ jj git clone --remote upstream https://github.com/upstream-org/repo
$ cd repo
$ jj git remote add origin git@github.com:your-org/repo
$ jj config set --repo git.fetch upstream
```
In the example above, `upstream` is the repository containing the
reference source code that you might want to patch, while `origin` is
your fork where pull-request will be pushed. The branch `main@upstream`
will be tracked.
