I was reading a draft of "Git Rev News: Edition 91" [1] where Peff
mentions some unfinished patches to allow negative timestamps in
Git. So I figured I should add support for that before I forget. I
haven't checked if libgit2 supports it, so it might be that our Git
backend still doesn't support it after this patch.
[1] https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-91.md
I changed the "GLOGAL OPTIONS" help heading to use title case, to
match clap's new help style.
I also removed our override of the help text for `-h, --help` because
the default text now includes "(use `-h` for a summary)" (and it's
harder override now).
Perhaps the most obvious difference to users will be the changed help
output
(https://epage.github.io/blog/2022/09/clap4/#polishing-help-output). It
no longer has color, and long lines are not wrapped. I suppose we
should wrap the text ourselves instead..
In many of these places, we don't need an owned value, so using a
reference means we don't force the caller to clone the value. I really
doubt it will have any noticeable impact on performance (I think these
are all once-per-repo paths); it's just a little simpler this way.
I feel it doesn't make sense for a simple getter function to create an
owned vec after 010867308714 "backend: let each backend handle root commit
on write."
This commit moves much of the `commands` module that isn't specific to
a particular command into a new `cli_util`.
Much of this is actually not even CLI-specific, so we should move that
further down into the library, but that can come later. That includes
the code in `WorkspaceCommandHelper` for snapshotting the working copy
and automatically importing/exporting to a colocated Git working copy.
I'm trying to make it easier to create a custom `jj` binary with
custom commands, without having to replace the `Args` type we parse
arguments into. For that to work, we need to resolve aliases using the
`clap::Command` type instead.
Now that open commits are disabled by default, seeing `close` and
`open` in `jj help` is confusing.
I'm a little ambivalent about hiding `jj commit` because it's useful
as a way of adding a description and starting a new change with a
single command. We can always add a new command for that if we want
to.
As pointed out by IntelliJ (maybe it came from rust-analyzer or
something, I don't know). I also lifted out
`Err(CommandError::UserError())` and extracted a variable.
Commands that take both paths and revisions as arguments take paths as
positional arguments and use `-r` for revisions (or more specific
options like `--from` and `--to`). It's therefore natural for the user
to think that they can run e.g. `jj describe -r abc123`. However,
since `jj describe` doesn't accept paths, it doesn't have a `-r`
argument either. Let's allow the user to specify a superfluous `-r`
that we just ignore.
This handling means that the user could run `jj show -r` (without a
revision argument) and it would use the default revision. That's
confusing, but at least we won't accept e.g. `jj show -r README.md`
(unless `README.md` is a revision), so it's probably okay?
`wc_commit` seems clearer than `checkout` and not too much longer. I
considered `working_copy` but it was less clear (could be the path to
the working copy, or an instance of `WorkingCopy`). I also considered
`working_copy_commit`, but that seems a bit too long.
In the current implementation, tree is diffed twice if both PATH and -p
are specified. If this adds significant cost, we'll need to reimplement
it without using a revset abstraction (or maybe adjust revset/graph API.)
Previously, using `rebase -r` on the parent of a merge commit
turned it into a non-merge commit. In other words, starting
with
```
o d
|\
o | c
o | b
| o a
|/
o
```
and doing `rebase -r c -d a` resulted in
```
o d
o b
| o c
| o a
|/
o
```
where `d` is no longer a merge commit.
For reference, here's a complete test that passed before this commit (but should NOT pass; see the diff for a test that should pass):
```
#[test]
fn test_rebase_single_revision_merge_parent() {
let test_env = TestEnvironment::default();
test_env.jj_cmd_success(test_env.env_root(), &["init", "repo", "--git"]);
let repo_path = test_env.env_root().join("repo");
create_commit(&test_env, &repo_path, "a", &[]);
create_commit(&test_env, &repo_path, "b", &[]);
create_commit(&test_env, &repo_path, "c", &["b"]);
create_commit(&test_env, &repo_path, "d", &["a", "c"]);
// Test the setup
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
@
o d
|\
o | c
o | b
| o a
|/
o
"###);
let stdout = test_env.jj_cmd_success(&repo_path, &["rebase", "-r", "c", "-d", "a"]);
insta::assert_snapshot!(stdout, @r###"
Also rebased 2 descendant commits onto parent of rebased commit
Working copy now at: 3e176b54d680 (no description set)
Added 0 files, modified 0 files, removed 2 files
"###);
insta::assert_snapshot!(get_log_output(&test_env, &repo_path), @r###"
@
o d
| o c
o | b
| o a
|/
o
"###);
}
```
While debugging stale working-copy recovery, I noticed the checkout commit
resurrected from the ancestor_op was way beyond the ancestor commit made by
jj squash. This patch is a workaround for the problem.
I'm not pretty sure if updating operation id is the right thing. If not, maybe
we'll need to look up more recent operation corresponding to the wc tree id from
the <ancestor_op>: range?
I keep explaining the functionality as hiding the commit, so it seems
that `jj hide` is a natural name for it. Let's start by adding it as
an alias. My only hesitation with making `hide` the real command name
and `abandon` an alias that we start phasing out is that it feels more
natural to `abandon` the working copy in order to start working on a
new change than it does to `hide` it.
Add the `jj interdiff` command for comparing only the diffs of commits.
Its args are identical to that of `jj diff`, minus `--revision` (because
interdiff always requires two commits).
Like `jj obslog -p`, Changes introduced by intervening commits are
ignored by rebasing `--from` onto `--to` 's parents.
`jj merge` just creates an empty change, which is practically the same
as `jj new`. The main difference is that the former requires more than
one argument and the latter requires at most one argument. It seems
cleaner to generalize them and make them aliases. This patch starts
doing that by making `jj new` accept more than one argument.
Instead of having `jj merge` be exactly an alias for `jj new`, we may
want to make it a thin wrapper that just checks that more than one
argument was given. That would probably be less confusing to users who
run `jj merge` without arguments to see what it does.
We should probably make `jj checkout` also be an alias for `jj new`,
but that will have to wait until we have removed support for open
commits (since `jj checkout` still has logic for dealing with open
commits).
In 8ae9540f2cc7, I made `jj move/squash/unsquash` not abandon the
working copy if it became empty because that would lose any
description associated with it. It turned out that the new behavior
was also confusing because it made it unclear if the working-copy
commit was actually abandoned. Let's roll back that change and instead
ask the user for a combined description when both the source and
destination commits have non-empty descriptions. Not discarding a
non-empty description seems like a good improvement regardless of the
behavior related to working-copy commits. It's also how `hg fold`
behaves (though hg doesn't allow the description to be empty).
I was using a custom `jj log` command and had some trouble finding
the commit `jj merge` created. The default `jj log` command shows it
by default, but my custom one didn't.
The two commands are very similar and we should probably make one an
alias of the other (or just delete one), but for now let's at least
make them more similar by supporting `-m` for both.
I currently think `jj new` is more natural when starting a new change
on top of the current one and `jj checkout` is more natural when
starting a new change on top of another one, as well as when you just
want to look around or run tests. `jj checkout` doesn't currently
default to the working copy like `jj new` does. Perhaps we should make
it do that. Will people eventually feel that it's natural to run `jj
checkout` to create a new change on top of the working copy, or will
they feel that it's natural to run `jj new` on an unrelated commit
even to just look around, or will we want them as synonyms forever?
We have supported conflicts in the working copy for a long time (since
ea823406541e), but I had forgotten to update a few references to the
old behavior.
