These assertions were there to catch bugs, but when the bugs happen,
the assertions can obsure the underlying error (as @tp-woven found out
on #258). Let's just print errors instead.
We don't even have any settings that affect the repo, so there's no
point in passing the settings. I think this was a leftover from before
we separated out the "workspace" concept; now we no longer create a
working-copy commit when we initialize a repo (we do that when we
attach the workspace).
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.
The help text said you can `jj abandon; jj co @-` to go to the parent
commit (it it's an open commit), but `jj abandon` already takes you to
the parent.
We don't need the `config` crate's support for JSON etc., so let's
just enable the TOML feature. (Trying to import all the JSON, RON,
dependencies etc. into Google's source control was a pain.)
Mercurial has these aliases, so it will be familiar for Mercurial
users. My only hesitation about adding these aliases is that we might
want the these names for something else in the future. You could
imagine `up` and `down` commands, for example. We still have a long
time before 1.0, so we have plenty of opportunity to make breaking
changes if we think of some other use for the names :)
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.
The request to show the log output with more recent commits at the
bottom comes up once in a while (among Mercurial users, and now also
for jj from @arxanas). It's pretty easy to implement by adding an
adapter to the current `RevsetGraphIterator`. It works by first
collecting all nodes and edges into a vector and then yielding them in
reverse order and with reversed edges. That means it's no longer lazy,
but that seems fine since the feature is optional. Also, it's only the
subset of nodes that are in the selected revset that will be
collected.
Making the CLI use the new iterator adapter will come in a later
patch.
The default log output of showing all commits is not very useful when
contributing to an existing repo. Let's have it default to showing
commits not on any remote branch instead. I think that's the best we
can do since we don't have a configurable main branch yet, and we
don't even have per-repo configuration..
Closes#250.
`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.
If a chain ends, we don't count the chain itself when calculating the
padding to use before text. This patch updates a few tests to use
multi-line descriptions so this is seen.
We actually already have a case of this bug `test_operations.rs`. I
noticed that when I added that test, but it didn't bother me enough to
fix it until now.
It's much easier to update the tests with `insta`.
It also presents you with the bad output including real newlines (a
diff, actually), so we can remove the `println!()` calls we had in
order to get readable output without escaped newlines.
With this patch, the order is this:
`$JJ_EDITOR` environement variable
`ui.editor` config
`$VISUAL` environement variable
`$EDITOR` environement variable
`pico`
That matches git, except that git falls back to an editor determined
at compile time (usually `vi`) instead of using `pico`.
It's much easier to tell users on all platforms to put their config in
`~/.jjconfig.toml` than in a path that varies across the platforms, so
let's do that. It also seems like a less controversial location for
the file.
Closes ##233.
As I said in 095fb9fef4, removing support for `~/.jjconfig` was an
experiment. I've heard from a few people (including in #233) that they
would prefer to have configs in the home directory. This patch
therefore restores that functionality, except I added a `.toml`
extension to the file to clarify the expected format to users and
editors.
After this patch, we still allow configs in `$XDG_CONFIG_HOME` (and
the other paths used by `dirs::config_dir()`), but we error out there
are config files in both that location and `~/.jjconfig.toml`.
It's cleaner to have all the calls in one place, and this structure
will also make it easier to return other errors from the `dispatch()`
function.
Note that there's still a call to `process::exit()` inside `clap` when
it fails to parse arguments.
We didn't have any testing of exit codes on failure, other than
checking that they were not 0. This patch changes that so we always
check. Since we have the special exit code 2 (set by `clap`) for
incorrect command line, I've replaced some testing of error messages
by testing of just the exit code.
As part of this, I also fixed `jj branch --allow-backwards` to
actually require `-r` (it didn't before because having a default value
means the argument is considered always provided).
The function only needs a mutable reference (it doesn't store an owned
value anywhere), and this will enable the caller (i.e. `main()`) to
use the `Ui` instance after control returns from `dispatch()`.
The conditions for triggering Nix builds and other builds were
slightly different.
Nix builds triggered by PRs happened on PRs for any branch, not just
the `main` branch. That makes very little difference in practice
because PRs for other branches are very rare. Still, let's be
consistent. I decided to trigger the builds on PRs for any branch.
More importantly, Nix builds triggered by push were only done for
pushes to `master`, which is not what our main branch is called, so
those never happened.
