As @arxanas noted, it's hard to tell which commit is currently checked
out. Hopefully bright colors will help. Maybe setting a background
color would be even clearer, but that's harder to do because the
formatter doesn't support background colors yet.
While working on demos, I noticed that `jj log` output in the
octocat/Hello-World repo was unstable: sometimes the first parent of
the merge was on the left and sometimes it was on the right. This
patch fixes that by sorting the edges by position in the index just
before returning them. It seems that most applications would want
stable output so I put it in the `RevsetGraphIterator` rather than
doing at the call site in the CLI. I ordered them with the reverse
index position rather than forward because it seemed to make the
graphs in the git.git repo slight nicer, with the left-most edge going
between subsequent releases.
There performance difference is within the noise level.
It can take quite a while to record a demo. This patch adds a `--fast`
flag for reducing delays to a tenth of the usual. You can play the
recording with `asciinema play -s 0.1` to get close-to-normal speed
(except that command delays will be slower). That way you can adjust
timings with shorter round-trips.
If you rewrite a commit that's also available on some remote, you'll
currently see both the old version and the new version in the view,
which means they're divergent. They're not logically divergent (the
rewritten version should replace the old version), so this is a UX
bug. I think it indicates that the set of current heads should be
redefined to be the *desired* heads. That's also what I had suspected
in the TODO removed by this change. I think another indication that
we should hide the old heads even if they have e.g. a remote branch
pointing to them is that we don't want them to be rebased if we
rewrite an ancestor.
So that's what I decided to do: let the view's heads be the desired
heads. The user can still define revsets for showing non-current
commits pointed to by e.g. remote branches.
According to asciinema.org, it should be possible to change the title
after uploading, but I couldn't figure out how to do that. Let's set
it when creating the recording. That also means it's one less step to
perform when re-running scripts.
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).
Most commands are non-interactive, so this reduces duplication. We can
add another function for running a command and not waiting for a
prompt when we need it.
The CLI code for cloning a Git repo didn't use the usual
`finish_transaction()` method, because we didn't have support for
doing that on a repo that was creating half-way through a
command. That led to a bug where it would leave the initial checkout
(the one on top of the root commit) after checking out the correct
head.
This fixes a bug I've run into somewhat frequently. What happens is
that if you have a conflict on top of another conflict and you resolve
the conflict in the bottom commit, we just simplify the `Conflict`
object in the second commit, but we don't try to resolve the new
conflict. That shows up as an unexpected "conflict" in `jj log`
output, and when you check out the commit, there are actually no
conflicts, so you can just `jj squash` right away.
This patch fixes that bug. It also teaches the code to work with more
than 3 parts in the merge, so if there's a 5-way conflict, for
example, we still try to resolve it if possible.
`args` seems to make it clear that these are command-line arguments
(this is not Python, so there's no `*args`). It also avoids the risk
of conflicts and confusion with other matches (e.g. file patterns or
regexes).
