- Wrapped all lines to 80 columns (using `concat()` where able).
- Dedented all TOML values.
- Put all close parentheses on their own line (looks more balanced).
- Added trailing commas for variadic functions such as `concat()` and
`separate()`.
- Fixed "(redacted)" bug for `format_operation_redacted(op)`.
After the previous commit, `MergedTree` and `MergedTreeId` are almost
identical, with the only difference being that `MergedTree` is attached
to a `Store` instance. `MergedTreeId` is also equivalent to
`Merge<TreeId>`, since it is just a wrapper around it.
In the future, `MergedTree` might contain additional metadata like
conflict labels. Therefore, I replaced `MergedTreeId` with `MergedTree`
wherever I think it would be required to pass this additional metadata,
or where the additional methods provided by `MergedTree` would be
useful. In any remaining places, I replaced it with `Merge<TreeId>`.
I also renamed some of the `tree_id()` methods to `tree_ids()` for
consistency, since now they return a merge of individual tree IDs
instead of a single "merged tree ID". Similarly, `MergedTree` no longer
has an `id()` method, since tree IDs won't fully identify a `MergedTree`
once it contains additional metadata.
I'm planning to try to add conflict labels to `MergedTree` and
`MergedTreeId`, and it will be easier to add them if both are structs
with similar methods. Since we don't support reading/writing legacy
conflicts anymore (as far as I'm aware), I think it should be safe to
delete the `MergedTreeId::Legacy` variant now.
When cloning with the branch option:
- Only the specified branch will be fetched
- The trunk alias is only set if the specified branch happens to be the default branch
- The clone fails if the branch does not exist in the remote
This will help "jj bookmark track" know whether absent remote ref can be created
for the specified remote. "jj bookmark" subcommands shouldn't depend on
gix::Repository API.
Git-tracking tags will be stored there. I don't have a concrete plan for proper
remote tags support, but I think tags fetched/pushed internally can be recorded
as remote tags.
I sometimes want to see how commit description is evolved.
This patch adds a separate loop for diff of commit descriptions. This should be
okay since DiffRenderer wouldn't have more than one "long" formats.
Alternatively, we could add a fake TreeDiff entry so the commit description
would be represented as a file in all diff formats. I have no idea which would
provide better UX, so I chose the simpler one.
Closes#7202
This patch doesn't add builtin_evolog_redacted template because I'm not sure if
we want to collect evolution log for debugging purpose. The redacted template
can be added later if needed.
Add `-T/--template` flag to `jj op show` to allow custom formatting of
output, matching the functionality available in `jj op log`.
Also add `--no-patch` flag to suppress the diff.
`templates.op_log` remains available as a config setting, used as a fallback
when `-T/--template` is not specified.
Resolves#6980
This paves the way for the semantics of `jj undo` and `jj op revert` to
evolve independently. `jj op revert` is going to stay the low-level
command to apply the inverse of any operation. The new name is
consistent with `jj revert`, which applies the inverse of a commit.
`jj undo` on the other hand is planned to become a higher-level command,
which is more similar to, say, Ctrl+Z in typical GUI applications.
Running `jj undo` repeatedly will revert progressively older operations,
allowing the user to walk backwards in time. At the same time, `jj undo`
will lose the abilitly to revert arbitrary operations, to keep its
semantics simple and intuitive.
Related feature request "jj undo ergonomics":
https://github.com/jj-vcs/jj/issues/3700
This is technically wrong because multiple predecessors should be considered
integrated into the rewritten commit, but I don't have a good idea to mitigate
the "squashed" diff problem. In "op diff", content diffs from the first
predecessor is practically useful.
Closes#7090
Add a parents() method for `Operation` template objects, copied from the
implementation for `Commit`s.
The test case added in test_operations.rs was heavily inspired by
test_commit_templates.rs:test_log_parents().
Fixes#6979
Previously, the computation for the available display width
included a padding constant, but this value was then used as
an upper bound for the width of the bar. This meant the bar
would never fill the available screen width.
Since divergent/conflicted symbols no longer resolve to multiple revisions, it's
less scary to allow "large" revsets than before.
The config doc is removed because it's largely duplicated from the revsets doc,
and the config key will be removed.
#6016
This should produce better results at squash/split operations. Since "op diff"
targets can be flipped, this patch implements basic handling of reversed
predecessors graph. It should also work for sibling operations so long as there
are no multiple greatest common ancestors.
resolve_transitive_edges() takes additional "start" parameter. It might be
useful in order to omit transitive edges in evolution log. Since
walk_predecessors() usually tracks a single commit, it would be wasteful to
build a fully-resolved predecessors graph.
Since divergence doesn't mean the commit has been squashed from / split into
multiple commits, it doesn't make much sense to show divergent commits as a
single entry. So this patch turns "changes" into a map indexed by CommitId in
order to track divergent commits individually. The ModifiedChange type is also
reorganized accordingly.
If old commits had divergence, we can't reliably associate new commit with the
old one. In the original implementation, we worked around the problem by not
displaying diffs for such changes. In this patch, the latest "old" commit is
arbitrarily chosen. I think this is better than disabling diffs, and will help
integrating predecessors information. Change-id based deduction won't be used
if new commits exist in the predecessors map.
This basically means that the graph is sorted by "new" commits, then abandoned
commits follow. I'm thinking of integrating predecessors information into "op
diff", and it will make sense to identify changes by commit ids instead of
change ids there. Divergent commits will be displayed individually, and squashed
commits will have all predecessor commits including ones having different change
ids.
This should also fix "graph has cycle" issue. In the original implementation, we
mixed parent change ids of both new and old views, which could result in cycle.
Unfortunately, we can't reproduce a merge in bit-exact manner. The shape of the
commits graphs should be identical, but commit/change ids differ. I don't think
we would want to see the list of "identical" changes, so this patch disables
show_op_diff() for merge operations. "op diff" is unchanged because it doesn't
fail, and the diff functionality might be useful for debugging problems.
Alternatively, we could show diff from the auto-merge state without rebasing
descendants, but I don't think that would be useful either. The state before
rebase_descendants() isn't visible to users, so it shouldn't be the stuff the
user would care about.
Fixes#4465
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<_>.
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.
Since the default remote bookmark is tracked at the end of "jj git clone"
command, it's probably better to show that in the stats output. I originally
implemented it the other way because "git clone --no-checkout" wouldn't create a
local bookmark. However, the tracking bookmark is unrelated to the check-out
state in "jj", so I think it's okay to set up tracking within the "fetch"
transaction.
We haven't had any reports of problems from people who opted in. Since
it's early in the release cycle now, let's now test it on everyone who
builds from head, so we get almost a month of testing from those
people before it's enabled by default in a released version.
This impacts lots of test cases because the change-id header is added
to the Git commit. Most are uninteresting. `test_git_fetch` now sees
some divergent changes where it used to see only divergent bookmarks,
which makes sense.
This makes it easier to override just the default description without
having copy the whole default template (and having to keep it up to
date with new versions).
With this template, a 'git format-patch' compatible
email message can be generated using something like:
jj show --git --template git_format_patch_email_headers <rev>
This moves the default template to `builtin_draft_commit_description` and
points `draft_commit_description` to it. This makes it easier to override
the template while still being able to refer to the default.
AFAICT, this option was needed when we're going to abandon hundreds of commits.
However, I typically notice that I had to use --summary to suppress the output
after the fact. Since the list is now truncated up to 10 commits, I don't think
the --summary flag is useful anymore. This patch also removes the special case
for 1 item, which existed primarily for overriding --summary.
