This also allows some minor optimizations to be performed, such as
avoiding recomputation of the connected target set when
`MoveCommitsTarget::Roots` is used since the connected target set is
identical to the target set (all descendants of the roots).
is_empty() could also return Result<bool, _>, but I think the current definition
is also good. If an error occurred, revset.iter() would return at least one
item, so it's not empty.
This was added at f5f61f6bfe36 "revset: resolve 'HEAD@git' just like other
pseudo @git branches." As I said in this patch, there was no practical use case
of the HEAD@git symbol.
Suppose we implement colocated workspaces/worktrees #4436, there may be multiple
Git HEAD revisions. This means HEAD can no longer be abstracted as a symbol of
the "git" remote.
Custom backends may rely on networking or other unreliable implementations to support revsets, this change allows them to return errors cleanly instead of panicking.
For simplicity, only the public-facing Revset and RevsetGraph types are changed in this commit; the internal revset engine remains mostly unchanged and error-free since it cannot generally produce errors.
This is required when performing `rebase -s a -s b` where "b" is a
descendant of "a". Both "a" and "b" should be regarded as the roots of
the target set and be rebased onto the new destination.
This allows for `RebaseOptions` to be respected. This will be used when
migrating `rebase --source`/`rebase --branch` to use `move_commits` to
respect the `--before`/`--after` options.
Cleans up after 7051effa8f
It's split into "op_log operation" and just "operation" for the
summaries (as suggested by Yuya). The color labels use "operation".
We were discussing whether `jj backout` and `jj duplicate` should
support `-d/-A/-B` just like `jj rebase` does. `jj new` already
accepts `-A/-B` but it does not accept `-d`. It does support `-r`,
however. It seems like `-d` is a better match for `jj new` since it
creates a commit on top. So this patch adds support for that flag
too. I now think `-r` sounds misleading for `jj new`, but I left it in
for now.
A new module is added to jj_lib which exposes a function
get_annotation_for_file. This annotates the given file line by line with
commit information according to the commit that made the most recent
change to the line.
Similarly, a new command is added to the CLI called `jj file annotate` which
accepts a file path. It then prints out line by line the commit
information for the line and the line itself. Specific commit
information can be configured via the templates.annotate_commit_summary
config variable
Added colons to make it seem less like an English sentence, see
https://github.com/martinvonz/jj/pull/4602#discussion_r1791295776
I believe printing both the start and end times is excessive for a
summary. For now, I have it print just the start time for consistency.
I intend to change it to print the ending time later.
I was a bit torn on whether to use `format_timestamp(self.time().start())`
or `self.time().start().ago()`. The latter looks better, but is less
configurable and worse for dates long ago. In the future, we could add a
`format_op_summary_timestamp` function and/or a template function that
uses `.ago()` for recent dates and absolute dates for old dates.
This ensures that the data printed through the raw stream is colorized if the
formatter already had color labels, and if the raw data doesn't reset the
surrounding color. This would only matter in templates containing
label(.., raw_escape_sequence() ..) expression.
Fixes#4631
This adds `raw_escape_sequence(...)` support for things that use
FormatRecorder like wrapped text / `fill(...)` / `indent(...)`.
Change-Id: Id00000004248b10feb2acd54d90115b783fac0ff
move already supports these, so this improves squash's parity (I believe
squash is strictly a superset now) as we inch towards deleting move.
Change-Id: Id00000005f2a7f551cb7a0aa598c6265091a32d1
The default clap's help command doesn't have the ability to accept flags
(e.g --no-pager). The recommended way[1] to solve this is to manually
implement it.
[1]: https://github.com/clap-rs/clap/discussions/5332Fixes: #4501
`jj git push` has a `--bookmark` argument, which takes a list of
bookmarks to push to the Git remote. They'll become branches on the
Git remote. `jj git fetch` has a `--branch` argument, which takes a
list of Git branches to fetch. They'll become bookmarks once
fetched. So the naming is consistent, but the reasoning is quite
subtle. Let's provide the other name as a hidden alias to help users
who get it wrong.
These flags only apply to line-based diffs. This is easy, and seems still useful
to highlight whitespace changes (that could be ignored by line diffing.)
I've added short options only to "diff"-like commands. It seemed unclear if
they were added to deeply-nested commands such as "op log".
Closes#3781
Most collection references implement `.into_iter()` or its mutable version,
so it is possible to iterate over the elements without using an explicit
method to do so.
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.
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.
