cg

cg = Crockeo's Git (UI)

Building out something like magit as a TUI. Similar to gitu, but laser focused on "fast enough to use in the monolith at $JOB."

Keeping notes on what I should do, in what order :)

• System to perform predictive updates. When a user takes an action, in many cases the result is already known. E.g. staging will cause the hovered item to appear in the staged area. We should make it easy to update the repo state such that an action appears to occur immediately, and then update it with the real state when the background job is finished.

• System to show potential inputs. Render a pane on the bottom of the screen which shows the valid contextual inputs based on the input sequences in the InputMap. Also include a ? command which shows available top-level commands.

• System to pipe output from subprocesses. For example, when we run git commit we want to stream the output of pre-commit hooks to a buffer that's visible on the bottom of the screen.

• Scrolling output When there are many changed files, we need a system to allow the output to be truncated and scrolled. This also implies being aware of the total size of the screen, and therefore responding to SIGHUP.

• Foreground
  • Responsible for all user interaction, input processing + painting the frontend.
  • Painting thread
    • Receives signals that it should paint from any source (background job or user input)
    • Takes mutex on shared state and paints
  • Input thread
    • Reads input from stdin as byte strings, and translates it to a logical input
    • Takes mutex on user state and performs some action based on that input
    • Can send messages to background job
• User State
  • Stores information related to the user.
  • E.g. "what index have I selected"
  • Or "what partial input have I applied"
    • This is to capture the idea of an input sequence resulting in one action.
    • E.g. c -> should open up the "commit" menu, and there should be many options inside of the commit menu.
  • Can be "merged" with a repo state to make sure it is valid w.r.t. the current state of the repo.
• Repo State
  • Stores information related to the repo.
  • E.g. the current status, branches, remotes, etc.
• Background
  • Just a single background thread, which can accept a queue of work.
  • Each job looks like:
    • Take job description
    • Do
    • Produce a new repo state
    • Take mutex on current repo state and swap it out for the new repo state

Requires zig and the git CLI:

zig build run