Our readme says that pull request require too many manual steps. I
think that refers to the manual abandoning of merged commits that was
necessary before 57ba9a940976; I think the workflow works reasonably
well these days. So let's avoid scaring away potential new users by
mentioning that old problem.
The demos don't need to be animated - the user wouldn't miss anything
if they skipped to the end. So let's just show the full output so the
user can read through it at their own pace. We could use plain text,
but I think the colors are helpful, so I went with screenshots.
Closes#166.
As @huyz noticed, I accidentally lost the undo demo in 0d1bf7cb3b. I
also didn't update the working-copy demo. This patch fixes that by
updating all demos, so we also get the recent styling change from
af145c998ea4..
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.)
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".
We have `rust-version = "1.60"` in `Cargo.toml`, but Cargo doesn't
check that until after dependency resolution, which fails if you have
an older version (I don't know why).
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.
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.
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.
I'm a little hesitant to do this because most tools I'm familiar with
have the config file directly in `~/`. It's also easier to describe
where to put the file if it doesn't vary across platforms. But we're
still early in the project, so let's try it and see if we get any
complaints.
Users now have the option of installing from source or directly
installing a binary.
I also corrected some text that effectively said that installing a Nix
flake is not installing from source, but I think it actually does
install from source.
A few people in different forums asked if there's any reason to use
the native backend and what the reason for its existance is, so let's
document that.
The only overlap between the instructions for Linux, Mac, and Windows
is the `cargo install` step, so let's instead split it up so it's easy
for the user to skip to the relevant part, especially as we add more
platform-specific instructions.
I promoted some sections to one level higher sections to try to
clarify that the initial configuration and the command-line completion
applies to all platforms.
Since #85, we load the user's config from a path under
`dirs::config_dir()`. It's probably not obvious to all users where to
put the file, so let's describe that. (I didn't know where to put the
file on my Mac until I looked at the function's documentation.)
