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.)
I find it frustrating to wait for the typing, but I need much more
time to think between commands (and users who are new to the tool
surely need even more time).
I also changed the instructions to use `cargo install --git` pointing
straight to GitHub, so we don't have the naming conflict with the jj
repo created in the tutorial.
I think it makes sense to have a version of rebase that rebases the
descendants of the rebased commit onto the parents of the rebased
commit. Let's make `jj rebase -r` do just that. Let's also add `jj
rebase -s` (matching Mercurial's `hg rebase -s`) for rebasing a commit
and its descendants onto another commit.
Since both flavors of the command now explicitly rebase the
descendants (just to different destinations), I also made the command
not evolve orphans afterwards. That would have made sense regardless
of this commit.
Now that our own branches and tags are updated when git refs are
updated and the user can use them to specify revisions, we can start
displaying them instead of the git refs. This commit adds new
`branches` and `tags` template keywords and updates the default
templates to use them instead of `git_refs`.
This copies the conflict marker format I added a while ago to
Mercurial (https://phab.mercurial-scm.org/D9551), except that it uses
`+++++++` instead of `=======` for sections that are pure adds. The
reason I made that change is because we also have support for pure
removes (Mercurial never ends up in that situation because it has
exactly one remove and two adds).
This change resolves part of issue #19.
This both helps find the current checkout and head operation and
hopefully helps teach the user that "@" is the symbol for the working
copy. I removed the current "<--" indication from the graph (and
non-graph) log template. Hopefully the "@" is clear enough on its own,
but we may want to add back some further indication later. We'll see.
I considered even changing the message to "Checking out: <commit>" as
that's technically more correct (the message is printed when the
view's checkout is updated, i.e. before the working copy is
updated). However, I worried that users would find it confusing that
e.g. `jj close` would result in a "Checking out: " message, even
though that's what actually happens.
I remember adding that message a long time ago so the user has a trace
of working copy commit ids in the terminal output. They should be able
to get the same information from the operation log combined with
e.g. `jj st --at-op`.
The project is starting to work well enough that I think it's time
that the documentation targets users instead of VCS hackers. This
patch rewrites much of the README to describe how the features help
the user instead of describing how they work. It also adds a tutorial.
