Since we've moved the default log revset to config/*.toml at 3dab92d2, we don't
have to repeat the default value. It can be queried by "jj config list". I also
split the help paragraphs.
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'.
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.
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
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.
"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.
