We have talked about showing the commit ID only for divergent changes
because it's generally easier to work with the change ID, and it's
less likely to result in a divergent change. However, it's useful to
have the commit ID available for pasting into e.g. a commit message or
the GitHub UI. To try to steer users towards using the change ID, this
commit moves the commit ID off to the right in the log output.
I put it just after the "divergent" field, because that makes it close
to how I imagine it would look if we decided to hide the commit ID
except for divergent changes. I was thinking that could be rendered as
"divergent (abc123)". So if we add config to hide the commit ID, then
it would be rendered almost the same for divergent commits (just with
the added parentheses). It would also make sense to replace the
"divergent" field by a question mark on the change ID, since change
IDs basically behave like branches. If we do that, then the placement
of the commit ID I picked in this commit does not make sense.
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.
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 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.
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.
