We could instead implement serde::Serialize wrapper manually, but it would be
tedious to process recursive data structure. Let's just rely on the toml crate.
The cost of conversion wouldn't matter.
Instead of requiring L::Property type, make it the default type parameter which
can be specified as needed. This helps remove unnecessary trait bounds from
later patches.
The operation timestamp is often very close to the committer timestamp, so I
don't think it's useful in evolog. I also removed "root()" as it wouldn't be
useful either, and the root operation should have no evolved commits.
I got annoyed by the checkout function and tried to compress the code a bit,
and I think the result is much nicer. I'm not certain that a closure is the
right solution here, but I think it becomes easier to reason about the two
temp filenames that get generated.
I initially changed `Option<DiffSide>` to a bool, but found an enum more
meaningful and more likely to be flexible in the future.
I also moved the instruction writing to its own function. This makes the main
`DiffEditWorkingCopies::check_out()` function much nicer.
New users (especially ones unfamiliar with CLI programs) intuitively
expect `jj undo` to work the same way the "undo" functionality of
typical GUI applications do. That means, running `jj undo` multiple
times should restore progressively older states of the repository
one-by-one.
Related feature request "jj undo ergonomics":
https://github.com/jj-vcs/jj/issues/3700
The only two cases where PathCompleter was used were simple enough to be
replaced with clap::ValueHint directly (since statically know the type
of file to be completed). This also makes things more consistent given
that we use clap::ValueHint everywhere else.
The main difference between PathCompleter and ValueHint is that
PathCompleter requires dynamic completion, wheres ValueHint works in
static situations.
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.
I don't have a strong feeling whether we should add "entry.commit() -> Commit"
method or forward method calls to the Commit object, but this patch implements
the former because:
a. evolution_entry.diff() should return inter diff, whereas commit.diff()
doesn't.
b. auto-labeling works if self.commit() is an explicit method call.
c. the implementation and documentation can be simple.
Tests will be added by the next patch.
This adds `builtin_log_compact(commit)` etc. and redefines
`builtin_log_compact` as `builtin_log_compact(self)`. That should make
it easier to reuse these functions e.g. in the the `jj evolog`
template.
This will allow us to use operation template types in the commit template.
OperationTemplateEnvironment and OperationTemplatePropertyVar correspond to
(a part of) TemplateLanguage and CoreTemplatePropertyVar respectively.
Add `--tracked` flag to `jj git fetch` that fetches only tracked bookmarks
from the specified remote(s). This is symmetrical with the existing `jj git
push --tracked` functionality and is useful in large repositories where
fetching all bookmarks is slow, and manually specifying each tracked bookmark
is cumbersome.
Conflicts with `--branch` to avoid confusion. When no tracked bookmarks are
found for a remote, a warning is displayed and the remote is skipped.
Resolves#7209
For example, with a commit tree like this one:
@ kkrvspxk (empty) (no description set)
○ lpllnppl file4
│ A file4
○ xynqvmyt file3
│ A file3
○ wkrztqwl file2
│ A file2
○ mzuowqnz file1
│ A file1
♦ zzzzzzzz root()
we can jj squash -f x:: -d m to squash xynqvmyt and all its descendant
as a new commit onto mzuowqnz.
@ youptqqn (empty) (no description set)
○ wkrztqwl file2
│ A file2
│ ○ vsonsouy file3 file4
├─╯ A file3
│ A file4
○ mzuowqnz file1
│ A file1
♦ zzzzzzzz root()
On the implementation side, I've chosen to prepare the destination
commit before hand, and keep the squash algorithm mostly unmodified.
`jj undo` is planned to become a higher-level command that progressively
undoes more operations when executed repeatedly (in a strict order).
This will be separate from the lower-level semantics of `jj op revert`,
which reverts arbitrary operations on top of the current one. The
semantics of the new, high-level `jj undo` won't make sense when
combined with specifying a specific operation to undo. Thus, start the
lengthy deprecation period right now.
Related feature request "jj undo ergonomics":
https://github.com/jj-vcs/jj/issues/3700
By default, `git clone` will fetch all tags (same as `git clone
--tags`), but since we perform a clone by creating a remote first then
fetching it, we have to be a little smarter and keep track of when we're
doing a clone so that we ensure all tags are fetched.
`git clone --no-tags` will skip fetching tags at all, and so this is
also the now the behavior of `jj git clone --fetch-tags none`
Closes#4682
By default `git clone` will fetch all tags on a remote (unless
`--no-tags` is specified). Eventually we'll want to support the same
behavior, though since we first configure a remote and then fetch, we'll
need to configure the remote with the correct *general* tag fetching
behavior, but still perform the first fetch with all tags included.
`jj undo` and `jj op revert` used to be aliases. Now that their
semantics are planned to diverge, we need to think about which of the
existing tests belongs to which of the commands. Since `jj op revert`
will keep the current low-level semantics, all of the tests naturally
belong to it. `jj undo` will incrementally grow a new set of tests
together with its new, higher-level functionality. Some tests are
duplicated, in anticipation that they will be meaningful for `jj undo`
as well.
The moved tests are left as-is, except for any references to "undo" are
replaced by "revert" and invocations of `jj undo` are replaced by
invocations of `jj op revert`.
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
When both `origin` and `upstream` are present, prefer `upstream` over `origin`
as the default remote for the `trunk()` alias.
This allows developers working on forks to have `trunk()` automatically point
to the `main` branch of the upstream repository rather than their fork's
origin. This is common when using the `gh` CLI to set up repositories.
Resolves#7228
This allows checking whether "any" or "all" elements in a list satisfy a given
predicate, similar to Python's native `any()` and `all()` functions, but
instead as list methods that take lambda predicates.
These new methods follow the same pattern as existing `filter` and `map`
operations, i.e. taking a lambda that receives each item and must return a
boolean.
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 paves the way for `jj undo` and `jj op undo` to evolve
independently. The planned changes revolve around making `jj undo` a
more high-level command and renaming `jj op undo` to `jj op revert`,
keeping the low-level semantics.
Related feature request "jj undo ergonomics":
https://github.com/jj-vcs/jj/issues/3700
