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`.
We already support using "@" to refer to the head operation when doing
e.g. `jj op undo -o @`. This patch adds support for `--at-op=@`. It
also makes that the default.
This prepares `jj status` for working better on an old repo state
(with `--at-op`). When looking at an old repo state, the "working
copy" should reflect the state from that state, i.e. the view's
"checkout", not the current working copy.
Before this patch, `jj log` would always commit the working copy and
most other commands would commit the working copy only if they were
passed a revset of exactly "@". This patch makes it so they all commit
the working copy unless they are passed just a symbol other than "@"
(typically a commit id). That means that we will not commit the
working copy if the user does `jj diff -r abc123`, but we will if they
do `jj diff -r :abc123`. It's clearly unnecessary in both those cases,
and we should fix, but this is probably good enough for now.
This patch adds checks in all (?) commands that rewrite commits to
make sure the commit they're about to rewrite is allowed to be
rewritten. The only check we do is that it's not a root commit. We
should at least add checks for public commits later.
Now that we auto-evolve after most operations, the user may not know
what "evolve" means. Even before that, the way `jj evolve` resolved
orphans after pruning was by rebasing them.
Perhaps it makes more sense to display the working copy commit just
above the changes in the working copy commit, even though that means
that the order between the working copy commit and the parent becomes
the opposite of the order in `jj log`.
I had initially hoped that the type-safety provided by the separate
`FileRepoPath` and `DirRepoPath` types would help prevent bugs. I'm
not sure if it has prevented any bugs so far. It has turned out that
there are more cases than I had hoped where it's unknown whether a
path is for a directory or a file. One such example is for the path of
a conflict. Since it can be conflict between a directory and a file,
it doesn't make sense to use either. Instead we end up with quite a
bit of conversion between the types. I feel like they are not worth
the extra complexity. This patch therefore starts simplifying it by
replacing uses of `FileRepoPath` by `RepoPath`. `DirRepoPath` is a
little more complicated because its string form ends with a '/'. I'll
address that in separate patches.
I thought I had looked for this case and cleaned up all the places
when I made `Transaction::commit()` return a new `ReadonlyRepo`. I
must have forgotten to do that, because there we tons of places to
clean up left.
If you ran two concurrent `jj describe` (for example) before this
patch, they'd both try to open an editor on the same file. This patch
fixes that by randomizing the filename. It also deletes the file at
the end so the `.jj/` directory is not cluttered by these files.
It's annoying to have to run run `jj evolve`, and it's easy to forget
(especially after updating the description of the working copy
parent), so let's just always do it. Unlike most VCSs, we don't have
to worry about merge conflicts since we can represent them in commits.
This commit rewites the divergence-resolution part of `evolve()` as an
iterator (though not implementing the `Iterator` trait). Iterators are
just much easier to work with: they can easily be stopped, and errors
are easy to propagate. This patch therefore lets us propagate errors
from writing to stdout (typically pipe errors).
When using the command line interface (which is the only interface so
far), it seems more useful to see the exact command that was run than
a logical description of what it does. This patch makes the CLI record
that information in the operation metadata in a new key/value field. I
put it in a generic key/value field instead of a more specialized
field because the key/value field seems like a useful thing to have in
general. However, that means that we "have to" do shell-escaping when
saving the data instead of leaving the data unescaped and adding the
shell-escaping when presenting it. I added very simple shell-escaping
for now.
Almost all commands should update the checkout after rewriting
commits, so this patch teaches the `RepoCommand` helper to take care
of that by default.
This patch introduces a type that keeps some state that is used by
commands that act on a repo (i.e. most commands). The short-term goal
with this refactoring is to use the new type for passing the full
list of command-line arguments as metadata on the transaction.
This patch on its own is a net increase in lines of code. Hopefully
that can be reversed with some further patches.
This commit adds support for defining command aliases. The aliases are
read from the `[alias]` section and are expected to be TOML arrays
with one element per argument.
When rendering a non-contiguous subset of the commits, we want to
still show the connections between the commits in the graph, even
though they're not directly connected. This commit introduces an
adaptor for the revset iterators that also yield the edges to show in
such a simplified graph.
This has no measurable impact on `jj log -r ,,v2.0.0` in the git.git
repo.
The output of `jj log -r 'v1.0.0 | v2.0.0'` now looks like this:
```
o e156455ea491 e156455ea491 gitster@pobox.com 2014-05-28 11:04:19.000 -07:00 refs/tags/v2.0.0
:\ Git 2.0
: ~
o c2f3bf071ee9 c2f3bf071ee9 junkio@cox.net 2005-12-21 00:01:00.000 -08:00 refs/tags/v1.0.0
~ GIT 1.0.0
```
Before this commit, it looked like this:
```
o e156455ea491 e156455ea491 gitster@pobox.com 2014-05-28 11:04:19.000 -07:00 refs/tags/v2.0.0
| Git 2.0
| o c2f3bf071ee9 c2f3bf071ee9 junkio@cox.net 2005-12-21 00:01:00.000 -08:00 refs/tags/v1.0.0
| |\ GIT 1.0.0
```
The output of `jj log -r 'git_refs()'` in the git.git repo is still
completely useless (it's >350k lines and >500MB of data). I think
that's because we don't filter out edges to ancestors that we have
transitive edges to. Mercurial also doesn't filter out such edges, but
Git (with `--simplify-by-decoration`) seems to filter them out. I'll
change it soon so we filter them out.
