Changing demo/settings.tape, or anything about how lazygit looks, dates
every recording at once, and re-recording them one at a time means
running the recorder fifteen times and pasting fifteen new URLs.
Attachment URLs say nothing about where they came from, so there is also
nothing to tell you which demo a video in the README is of.
Name the demo in a comment above each video. GitHub drops the comment
when it renders the page, so it costs the reader nothing, and it gives
us a way back from a page to the demo that produced it. Then walk those
comments, re-record each demo and rewrite the URL below it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The demo gifs in the README start on their own, loop without telling the
reader where a run begins, and give no way to pause, seek or replay. A
video with the browser's own controls fixes all three, but GitHub plays
a video in a README only when it is served from its own attachment
store. If you commit one to the assets branch and link it the way we
link the images, GitHub drops the whole <video> element when it renders
the page.
Replace terminalizer with vhs. vhs records the demo straight to mp4
rather than going through a gif, and it takes the terminal size, font
and colours from demo/settings.tape. Then upload the result from the
endpoint that GitHub's own drag-and-drop upload posts to, and print the
tag to paste into the page.
Uploading alone is not enough. An attachment is readable only by people
who are signed in to GitHub until a posted comment in the repository
refers to it, and a README on a branch does not count. So post each
recording to a collecting issue and wait until the video can be fetched
without a token. Miss that step and the video plays for whoever recorded
it and 404s for every other reader.
Two things about the frame. Pad the bottom, because the browser draws
its playback controls over the video and they are tall enough to cover
the line where the demos put their captions. And cut the end: vhs
records until the marker reaches the screen, by which time lazygit has
exited and the shell has painted its prompt back over the demo. A
browser holds the last frame of a video once it has played to the end,
so leaving those frames in would end every demo on a terminal prompt
and leave it there.
Pass --no-upload while you are still working on how a demo looks. That
writes the video to demo/output and stops, so trying out a colour or a
font costs nothing but the recording itself.
The recording is sharper and smaller than the gif it replaces, at
1866x1230 and 25 fps against 1140x828 and about 5 fps. It also costs the
reader nothing until they press play, whereas the gifs are fetched every
time the README is opened.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Users no longer enter separate staging or patch-building panels. Describe file
entry, pane switching, staging, and custom patch construction where those
actions now happen, and remove the deleted package from the developer guide.
Co-Authored-By: GitHub Copilot <copilot@github.com>
The plan is to keep the original docs and schema folders unchanged for the
duration of a release; we'll only continuously update the -master copies. Right
before a new release we will copy them over.
Stefan HallerandClaude Opus 5
