For me, the trickiest part of figuring out how to use the new options
was to realize that I should assume `--from @` when using them, and
that I should not think of `-r` at all.
We still need more docs, but I think this would be a helpful
pointer for experienced users wanting to experiment with this.
Follows up on 1e58ca2253https://github.com/jj-vcs/jj/pull/7162 introduced some interesting and
useful functionality, but I feel like we should not commit to the exact
UI it sets up. The current UI is great for experimenting with this
functionality, and I don't have an immediate idea for what exactly would
be better. I'm hoping that with time and some experience
using it, we'll come up with something. See
https://github.com/jj-vcs/jj/pull/7162#issuecomment-3212555183 for more
details on this thought.
The main goal is to point new users of `squash` to the old UI, both
because I think it's currently more intuitive for new people, and also
so that they don't feel like obligated to learn the new UI, and so that
they don't get paralyzed by choice.
Another, more minor, reason to mark this as "experimental" is that it's
currently under-documented.
Since the situation is a bit confusing, and following Martin's
suggestion, I also removed these from the changelog for now.
The top-level `immutable` and `conflict` labels we add to commits in
the node templates are also useful in the text part. For example, we
may want to color change ids for immutable commits differently (we do
that at Google). I also added a `mutable` label, to make it easier to
define colors for mutable commits without having to define the color
for all commits and then overriding it for immutable commits.
I didn't bother with a deprecation process because the impact is so
small. Users who have customized the color can simply update their
configs. They can even keep both configs if they want to be able to
use old and new jj versions.
With this patch, init() would no longer panic when the checkout state already
existed. This should be okay because the caller always create new workspace
directory.
This is the natural counterpart of `jj undo`. Adding `jj redo` closes
the last gap in functionality to the "undo" features of typical GUI
applications. This is much more intuitive to new users and useful than
the previous undo semantics. (Which are preserved as `jj op revert`.)
Related feature request "jj undo ergonomics":
https://github.com/jj-vcs/jj/issues/3700
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 changes the behavior of git fetch to respect the fetch refspecs
configured on the remote. This is handy for projects which use
customized fetch refspecs (e.g. only fetch certain patterns, but not all
branches) but without having to remember and repeat all the patterns by
hand on the CLI
Fixes#5323
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.
Since Index is now implemented for CompositeIndex instead of &CompositeIndex,
these two functions have exactly the same signature. We no longer need a
specialized implementation to correct lifetime of the return value.
