[Worktree] Prune worktrees, and lock or unlock them (part 3) - #723

Slice 3 of #675: prune worktrees, and lock or unlock them, with a check of git's version that the remaining slice builds on.

Changes

• The menu of a branch another worktree holds is the same in the sidebar and on its label in the history list, and gains the worktree actions as a group of their own:

  Open Worktree of Branch "X"
  Copy name "X"
  ----
  Reveal Worktree in Finder
  Lock Worktree... / Unlock Worktree
  ----
  (branch items, unchanged)
  

  A detached worktree has no branch, so its sidebar row offers Lock or Unlock and Reveal Worktree in Finder alone. Lock asks for an optional reason on a sheet; git keeps it and the row's tooltip shows it. The main worktree's Lock is disabled and says why, since git refuses to lock it.

• The WORKTREES header gains Prune Worktrees..., which shows git's own dry run (git worktree prune --dry-run --verbose) before anything is removed. It is enabled when a worktree is prunable or its folder is gone; moving a folder away touches nothing in .git, so the menu checks the folders itself rather than wait for the list to be re-read.

• Locked and unavailable worktrees are marked, following JetBrains' IDEs, which show nothing until a worktree is locked or prunable. A locked row gets a lock where the checkmark goes, without the checkmark's pill but in the pill's colour, so it follows the checkmark through every state: row selected or not, window active or not. A row git reports prunable, or whose folder is not there, is dimmed and says which in its tooltip. Double-clicking one, in the sidebar or on a branch label, explains the missing folder (connect the disk, or prune) rather than failing to open it.

• Git version check: GitX keeps the version it read when it accepted the git binary, and each action checks it against what it needs.

• Fix a crash when no git binary is found, in its own commit: the worktree lookup called a method Show every worktree in the sidebar as the branch it holds #709 left declared but never implemented. The commit also drops the other declaration Show every worktree in the sidebar as the branch it holds #709 left without an implementation.

Screenshots

Lock Worktree

Worktree is Locked

Older git

GitX accepts any git from 1.6.0 (MIN_GIT_VERSION), but the worktree commands arrived later. Checked against builtin/worktree.c at each git tag:

As agreed on the issue (comment):

• Before 2.10, Lock is shown disabled with a tooltip naming the version needed and the one found.
• Before 2.31 git does not say whether a worktree is locked or prunable, so both Lock and Unlock are offered, and Prune is always enabled; its dry run decides.
• Nothing falls back to editing .git/worktrees by hand, the porcelain stays plain rather than -z, and MIN_GIT_VERSION is unchanged.

Apple's git on macOS 13 and later is new enough for all of it; the checks matter for an older git picked up from PATH or set in the preferences.

Test plan

• make unit-test: 263 tests, 43 of them new, among them the version boundaries (2.9.5/2.10, 2.30.9/2.31) as plain strings, lock, unlock and prune against a real repository with a linked worktree, and the lock taking the pill's colour in all four states and when the window goes inactive. Each of the four commits passes on its own.
• In the Debug build, on a scratch repository with two linked worktrees: lock through the sheet with a reason, unlock, Reveal Worktree in Finder, and prune after moving a worktree's folder away, checking git worktree list after each step; the menu order read back from the live sidebar, with an item sent up the responder chain from it; and the lock, the dimmed row and the missing-folder sheet read back from the live app, after moving a worktree's folder away.
• The missing-folder and no-git fixes each started from a failing test.