This is slower than traversing commit.predecessor_ids, but allows us to show
associated operations alongside the commits. Since operations are (mostly)
traversed in chronological order, the evolution graph is also emitted in that
order.
Operation ids in test_op_abandon*() are changed because reparented operations
now preserve the predecessors mapping.
Since this patch will affect whether "jj evolog" can show the associated
operations, I added a changelog entry. It's still a bit vague, but I think we
can add a more detailed explanation later.
There are two major goals:
1. garbage-collect predecessor commits referenced by immutable commits.
2. show operations alongside predecessors in "jj evolog".
The predecessors field will be removed from the Commit object. Maybe we can
also remove (writer side of) the extras table from GitBackend.
"jj evolog" will traverse the operation history to build an evolution
graph. This will be slower than the current implementation, but it seems
tolerable for mid-size repository stored in a local disk.
(when the page cache is warm)
% time jj op log -T'"."' --no-graph | wc -c
50459
jj op log -T'"."' --no-graph 0.12s user 0.31s system 103% cpu 0.418 total
Suppose we're interested in recent modifications, the traversal can often be
terminate early. I also have an idea for indexing originating operations.
https://github.com/jj-vcs/jj/pull/6405
For old operations which didn't record predecessors, "jj evolog" will fall back
to commit.predecessor_ids(). That's why commit_predecessors is Option<_>.
closes#6587
Given a commit history like this:
○ ccc
○ bbb
◆ aaa
Parallelize *should* be able to create this:
○ ccc
│ ○ bbb
├─╯
│ ◆ aaa
├─╯
This is fine because `aaa` will not be rewritten --- its children will,
but neither `aaa`'s parents nor author information needs to be changed.
However, the current implementation checks _all_ commits in the
target set for rewritability, instead of only the commits that will
be rewritten.
This commit changes that. Now, only the commits whose parents *will*
change are checked for rewritability.
Using the `cfg_attr` attribute means the test is still compiled on non-macOS
architectures and checked but is ignored and not run, instead of running and passing.
The optional arguments for each shell were deprecated in #2945 and v0.19.0.
The `shell` argument is now required, and Bash completions are no longer generated by
default if `jj util completion` is run without any arguments.
To identify an `undo` operation, checking that the views of the "bad" op and its
grandparent are equal is necessary but not sufficient. For example, creating a bookmark
and then immediately deleting it also "resets" the view. This commit fixes this by also
checking the "description" in the operation metadata to identify "double undo" properly.
With this commit, the "double undo" warning is now shown whether users undid the latest
undo implicitly (with `jj (op) undo`) or explicitly (with `jj (op) undo <op set>` or `jj
(op) undo @`).
If undoing an older undo (prior to `@`), the warning is not shown.
- Undoing latest undo explicitly with `jj undo @`.
- Undoing an older undo (that is not the most recent operation).
- Undoing an undo multiple times.
- Undoing a bookmark deletion (a spurious "double undo" warning is shown).
The test snapshots serve to indicate point-in-time behavior, so we shouldn't encode the
behavior in the test names. A later commit will change the current behavior so that
undoing the latest undo explicitly by op id or with the `@` symbol will no longer differ
in whether a warning is shown.
Incidentally, there is currently no difference in behavior between `jj undo` ("bare
undo") and `jj op undo`, as the former simply shells out to the latter.
A warning alerts users to a situation they may not have expected, which applies here.
The warning now explicitly calls out which `undo` has been reverted by which `undo`.
Also made the following hint more concise.
This serves a similar purpose to Git's patch ID mechanism, however it is
slightly different in that it only compares commits which have the same
change ID as each other (divergent changes), and it does a full
comparison of the commits to see if they would have identical trees if
rebased onto the same parents. Since most changes aren't divergent, I
believe this should have a negligible performance cost in most cases.
I think skipping these commits by default makes sense for `jj rebase`,
since usually this will be a helpful behavior for the user. With this
behavior, a safe first step when encountering divergent changes would be
to rebase one branch on top of the other, since that will abandon any
divergent changes that have identical contents to existing commits,
leaving behind any non-trivial divergent changes for the user to resolve
manually.
Since operation templates have "operation" label, commit templates should have
"commit" for consistency.
The [colors] table is not updated to use the "commit" prefix. There are some
non-template outputs which use unqualified "bookmark"/"tag"/"git_ref" labels.
That's also a reason why "bookmark_list" template doesn't have a "bookmark"
context label yet. (We'll need to qualify the color definition as "commit
bookmark" so the whole bookmark list wouldn't be colorized as "bookmark".)
I'm thinking of adding a top-level context label consistently. If we added
"commit" to the summary template (in code), the status output would be labeled
as "working_copy commit ..", whereas log entries would be labeled as "commit
working_copy ..". The latter should be more correct since the "commit" label
is global.
Now the working-copy entry is highlighted in op log and bookmark list, which
I think is good.
The `previous_op_id` doesn't belong to the operation immediately before the
`current_op_id`. There is one operation in between, namely the latest snapshot taken.
It isn't necessary to include shebangs in scripts passed into
`util exec` since you're already explicitly calling out the shell you'd
like to use. This change removes shebangs from examples for `util exec`
and adds a note below calling this out.
This is just for completeness. I don't think this is practically useful, but the
:<format> syntax should work in both config files and command arguments.
Instead of saying to move configuration files from
`~/Library/Application Support` to `~/.config`, jj now tells you to move
configuration files from `~/Library/Application Support/jj` to
`~/.config/jj`.
The usage line originally showed `--from <REVSETS>|NAMES`, which was confusing as it
could be parsed as `--from (<REVSETS> or NAMES)`, rather than the correct `(--from
<REVSETS>) or NAMES`.
The order of the two arguments are now swapped, so that Clap displays it as
`NAMES|--from <REVSETS>` instead. Using bookmark names as the move targets should be
more common anyway. This is also consistent with the order in which the two arguments
are described in the command's doc comment.
This allows users to override the external tool set in ~/.jjconfig.toml. The
config variable is renamed to ui.diff-formatter to be consistent with the other
diff/merge editor settings.
--tool=:<format> support will be added separately.
Closes#3327
A divergent change could point to more than two commits, so the hint now suggests
abandoning unneeded commits rather than just one of them.
The `-r` flag is unnecessary for `jj abandon` as it is implied.
Also changed `<REVISION>` to `<commit_id>` to be clear that using the change id here
will not work.
This addresses part of #4414 and implements something akin to what's described in
@arxanas's [suggestion], with the exception that the editor contents don’t need to be
completely cleared, since whether cleared or not it is not obvious whether the user
intended to add an empty description or abort entirely.
[suggestion]: https://github.com/jj-vcs/jj/issues/4414#issuecomment-2359123535
The hint is not shown if an empty description is provided via `--message ""`, since the
user is explicitly bypassing the editor and wants to commit the change directly.
Otherwise, if a user exits the editor with an empty description (notwithstanding any
`JJ:` lines), it could be one of the following cases:
1. The user wants to commit the changes but no longer wants to add a description. The
hint can simply be ignored.
2. The user wants to commit the changes and add a description but accidentally exits the
editor. The second hint shows how to add a description to the parent commit.
3. The user no longer wants to commit the changes. However, a new commit is still
created to maintain consistent behaviour as when an empty description is provided via
the CLI. The first hint shows how to undo the commit.
