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.
`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
"###);
}
```
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 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).
libgit2 by default will respect config files present on a user's
machine---in particular, when creating a new repo, it will read
`init.defaultBranch` to determine what the name of the default branch
should be. This makes the tests non-hermetic, so disable that feature.
On my machine, `init.defaultBranch` is set in system config. Without
this patch, `test_git_colocated` and
`test_git_colocated_rebase_on_import` fail, but with this patch, they
pass.
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?
I was initially worried about the cost of always snapshotting the
working copy, so that's why e.g. `jj diff -r <some hash>` doesn't do
it. However, there's been a few caused by missing snapshotting, and
there are still a few (I just noticed it in `jj undo` while writing
this patch). Let's always do the snapshotting and if the user really
doesn't want it, they can pass `--no-commit-working-copy` (which we
should probably rename to `--no-snapshot-working-copy` or maybe just
`--no-snapshot`). That should reduce bugs and make the CLI more
predictable.
Two test cases were affected becasue `jj merge` also didn't snapshot
the working copy.
Before this patch, e.g. `jj co --no-commit-working-copy` would error
out, but now it will succeed (without touching the working copy,
leaving the working copy stale). That may be confusing, but it should
be easy to recover from (e.g. by `jj undo`). We can consider adding a
check for it later if it seems too confusing (it's probably rarely
something the user wanted).
Since we now allow pushing open commits, we can implement support for
pushing the "current" branch by defining a "current" branch as any
branch pointing to `@`. That definition of a current/active seems to
have been the consensus in discussion #411.
Closes#246.
Since whitespace change is barely visible in color-words diff, I think it
would be too verbose to add "\ No newline at end of file" marker. Let's just
append missing newline to make the command output readable.
It's convenient to push all changed branches every time with `jj git
push`, but sometimes I want to know which branches were actually
pushed. This make the command print what it's going to do.
I'll add a `--dry-run` mode and tests next.
I think I had not added tests for successful push before because I
thought there was some issue with testing it with libgit2. There *is*
an issue, which is that libgit2 requires the remote to be bare when
it's on local disk, but we can very easily make the git repo bare in
this test.
I also updated the error handling in the `git` module to not let
follow-on errors hide the real error and to not fail if two branches
moved to the same commit.
We used to check only if the destination already had a `.jj/`
directory. This patch changes that to check that the destination is an
empty directory.
Closes#399.
We didn't seem to have any. I included a test for #399.
The tests also showed how the debug formatting (`{:?}`) results in
escaped (e.g.) backslashes on Windows, which is not what we want, so I
also fixed that.
By adding `ui.open-commits=false` in your config, you can now make `jj
checkout` always create a new working-copy commit on top of the
specified commit. If the config is set, open commits will also appear
in the same color as closed commits in `jj log` etc. This will let
some of us experiment with the new UX before we decide if it's a good
idea or not. I left `jj close` in place because it's useful for
setting a description and creating a new commit in one step.
I didn't mention the new config in the release notes because I hope we
can reach a decision and remove the config before the next release.
I'm about to change how `jj checkout` works w.r.t. open/closed commits
(and in particular by moving some logic from the library crate to the
CLI), so let's make sure we have some test coverage.
This patch adds `jj obslog -p` for including the diff compared to the
predecessor (the first predecessor if there are several). If the
predecessor's parents are different, then we create a temporary tree
by rebasing the predecessor to have the same parents and we use the
result as base for the diff. That way, we avoid polluting the diff
with the changes caused by the rebase. (I don't think we currently
have any commands that can change both parents and content, so the
diff should always be empty for rewrites caused by a rebase.)
Working on this also reminded me that it'll be really nice when we
replace `jj obslog` by something based on the operation log - I really
miss seeing information about the operation in the output (like `hg
obslog` gets from its obsmarkers).
I was a bit surprised to see the message when I used `jj git push
--change @-` on a commit that already had a branch because I had
pushed it earlier.
The fix means that we instead print the message even if we later
abandon the transaction (so the branch-creation is not persisted)
because the commit is open, for example. That's already what happens
if the commit is missing a description, and since we're planning to
remove the open/closed concept, I don't think this patch makes it much
worse. We probably should improve it later by printing the message
only once the push has succeeded.
I often redirect the jj output to pager, so I set ui.color = "always" in
config file. This patch allows me to remove such config, and instead specify
--color=always only when needed.
According to the NO_COLOR FAQ, "user-level configuration files [...] should
override $NO_COLOR." https://no-color.org/
Unfortunately this makes it harder to test the $NO_COLOR behavior since the
test environment isn't attached to a tty. We could allocate a pty or
LD_PRELOAD shim to intercept isatty(), but I feel it would be too much to do.
https://github.com/assert-rs/assert_cmd/issues/138
This patch prevents perhaps pushing commits with an empty description
or the placeholder "(no user/email configured)" values for
author/committer.
Closes#322.
If the source commit becomes empty as a result of
`move/squash/unsquash`, we abandon it. However, perhaps we shouldn't
do that if the source commit is a working-copy commit because
working-copy commits are often work-in-progress commits.
The background for this change is that @arxanas had just started a new
change and had set a description on it, and then decided to make some
changes in the working copy that should be in the parent
commit. Running `jj squash` then abandoned the working-copy commit,
resuling in the description getting lost.
We had tests for `jj move` and `jj squash`, but not for `jj
unsquash`. I'm about to add a `--keep` option, so let's add tests for
the current behavior first.
Before this change, `jj new` would check out the new commit only if it
was created on top of the current commit. I never liked that
special-casing, and after thinking more about how the open/closed
should work (see discussion #321), I think we want `jj new` to behave
similar to how `git/hg checkout` works, so it can effectively replace
the current `jj checkout` command for the use case of starting new
work on top of an existing commit.
It can be confusing that some commits (typically the working copy)
don't have a description. Let's show a placeholder text in such cases.
I chose the format to match the "(no email configured)" message we
already have.
This should help make e.g. `squash` discoverable for users who search
the help output for "amend". It should also help users discover the
builtin abbreviations like `st` (for `status`).
This adds a `--reversed` flag to `jj log` to show commits with later
commits further down. It works both with and without the graph.
Since the graph-drawing code is already independent of the
relationship between commits, it doesn't need any updating.
`log -s/--summary` and `log --git` without `-p` don't do anything. I
also don't think it's very useful to pass these flags in an alias,
where you would then sometimes also pass `-p` to see the diff summary
in the output. We already have the `diff.format` config for that use
case. So let's make both of these flags imply `-p`.
I implemented it by making the `diff_format` variable an
`Option<DiffFormat>`, which is set iff we should show a patch. That
way we have the condition in one place, and the places we use it
cannot forget to check it.
Our support for aliases is very naively implemented; it assumes the
alias is the first argument in argv. It therefore fails to resolve
aliases after global arguments such as `--at-op`.
This patch fixes that by modifying the command defintion to have an
"external subcommand" in the list of available commands. That makes
`clap` give us the remainder of the arguments when it runs into an
unknown command. The first in the list will then be an alias or simply
an unknown command. Thanks to @epage for the suggestion on in
clap-rs/clap#3672.
With the new structure, it was easy to handle recursive alias
definitions, so I added support for that too.
Closes#292.
