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.
It seems that there's no way to just enable auto-merge without
specifying a merge strategy (presumably because some projects allow
several GitHub merge strategies), so I guess we'll have to live with
the strategy being duplicated between here and the project settings.
Our current version of `cpufeatures` was yanked so we needed to
upgrade at least that. Note that I had to add "UNICODE-DFS-2016" as an
allowed license for `cargo-deny`. I also had to upgrade `chrono` from
0.4.20 to 0.4.22 in the `Cargo.toml` files to prevent `cargo update`
from *downgrading* it in the lock file.
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.
To merge a Dependabot PR, I have to enable auto-merge (two clicks,
including one to confim) and then review and approve it. Since our
branch protections require the PR to be approved, it seems that that
should be enough. This patch adds a GitHub action that calls runs the
GitHub CLI to do that. It is based on
https://dev.to/slashgear_/how-to-automatically-merge-dependabot-pull-requests-with-github-actions--30pe
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).
I suppose it could be seen as a bug fix that we no longer discard a
description without asking, but it was intentionally done the way it
was before.
While at it, I also clarified that the source commit gets abandoned if
it becomes empty.
In 8ae9540f2c, 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.
