I feel the original -------/+++++++ pair is slightly confusing because
each half can be a separator by itself. I don't know what character other
than '-'/'+' is preferred, but let's pick '%' (for "mod") per @martinvonz
suggestion.
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.
I had missed that `Ui::write_commit_summary()` still shows open
commits in green even when open commits are disabled (as they are by
default these days). This patch fixes that.
The user can still override templates to format open commits
differently, but I'm not sure it's worth fixing that.
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.)
This will be a basic building block of 'jj log PATH'. The implementation
is naive, but works fine for small repos like jj. For mid-size repos,
there would be various areas which need to be optimized.
Fixes two pedantic issues with this paragraph:
* "either" describing more than two things
* I am not an expert, but I suspect that Pijul
supports "automatic rebase".
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
"###);
}
```
The workflow that was supposed to enable auto-merge for PRs from
Dependabot is failing like this:
```
Message: Resource not accessible by integration, Locations: [{Line:1 Column:72}]
```
I can't figure out why it's failing (maybe
https://github.com/cli/cli/issues/1314?), so let's just remove it.
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?
Otherwise directories containing files cannot be removed.
I think making files readonly is enough to tell user that the left side
cannot be edited, but I haven't tested that with Meld. If that's not enough,
we'll probably need to undo set_readonly_recursively() at exit.
