Skip to content

v1.35.0

Choose a tag to compare

@VictorQuilgars VictorQuilgars released this 08 Sep 18:02
5168574

Added

  • A clean working tree says what comes next, on the desktop too. The staging pane has offered next steps since v1.22.0 — publish this branch, push the commits waiting, pull what arrived, review what the branch would bring, and a list of things to start — but only inside the VS Code panel. On the desktop the same clean tree was an empty Unstaged list, an empty Staged list and a commit button that could not be pressed. It is the same card now, computed the same way and following the same rule: a row is drawn only when it is true of this repository — no Publish on a published branch, no Push 3 on a branch level with its upstream, and nothing to publish at all in a repository with no remote. Where a row leads to a list rather than to an action — apply a stash, switch branch, start from an issue — the desktop opens that section of the sidebar and scrolls to it, since the desktop stacks its sections instead of choosing one on a rail. Two things it never replaces: an amend being written, and a message already typed — a draft outlives the changes it was written for, and a card of suggestions over the top of it would take your own words off the screen without deleting them. And it waits until the working tree has actually been read before saying there is nothing in it. (#189)

Changed

  • Electron 32 → 44: the browser this app ships is supported again. An Electron app carries its own Chromium and its own Node, and Electron only patches the latest three majors. This one was twelve behind — the Chromium inside it was from August 2024 and had received no security fix since. It now runs the current stable, which is the whole point of the change; nothing about the app's own behaviour was meant to move with it. Two things do move, and neither is optional:
    • macOS 13 (Ventura) is now the minimum. Electron dropped macOS 11 in v38 and macOS 12 in v44. In practice this is a hardware line as much as a version one — every Mac that cannot run Ventura is an Intel one (broadly a 2017 model or older; 2018 for the Air and the mini, 2019 for the Mac Pro). Intel Macs that can run Ventura lose nothing: each release still carries its own x64 build beside the arm64 one, and the update feed serves both. For the rest, the build declares its floor (LSMinimumSystemVersion) so macOS refuses to open a version it cannot run — and the update feed now declares it too, so the updater no longer offers that version at all: v1.34.0 is where those Macs stop, working, rather than being replaced by something that will not start. Windows 10+ and the Linux builds are unaffected.
    • Notifications on macOS need a signed app. Electron 42 moved macOS notifications to the system's UNNotification API, which refuses to deliver for an application that is not code-signed — and this app is not signed today. On macOS the three Notify settings therefore do nothing until it is; nothing else in the app depends on them, and Windows and Linux notifications are unaffected.
      Also from the upgrade, and smaller: a dialog opened with no starting folder now opens on Downloads rather than on the last folder used, so Open a repository is told to start beside the repository you opened last. On Linux, Electron 38 made Wayland the default where the session offers it, and Electron 43 gives frameless windows rounded corners — the splash is one, so it looks slightly different there.
  • Every argument is looked at before it reaches git. The window runs sandboxed, the secrets never reach it and every request names the repository it is about — and then each handler took the arguments as they came. A ref, a file path inside the repository, a remote name, a clone URL: what checking existed was inside individual methods and by memory, not at the door. There is a door now. One table says what each git:* handler's arguments may be, and a call that breaks it is answered with a sentence saying which argument and why — never a rejected promise the window has to guess at. What it refuses: anything git would read as an option (--upload-pack=… as a branch name), control characters and newlines, a name for a new branch or tag that git check-ref-format would reject, a remote name with a slash in it, a clone URL whose scheme is neither http(s), ssh, git nor file — and a file path that leaves the repository, so a request for ../../.ssh/id_rsa is not a file of this repository whichever pane asked for it. What it does not do is invent opinions about missing values: an argument nobody sent, or sent empty, reaches the handler exactly as before. A test reads the handlers as they are written and fails when one grows an argument that looks like a path or a ref and the table says nothing about it — it found five the first time it ran. (#190)
  • The settings say what they change, and when they are kept. The page held two kinds of setting and presented them identically: what belongs to this app — a theme, an auto-fetch interval, an API key — and what writes Git's own global configuration, which every git client on the machine reads afterwards. The second kind now says so in the field itself, with the key it writes: Git global · user.name on the identity, Git global · core.sshCommand on the SSH key and the agent switch — the two places where a choice made here leaves this app. The fields that only look git-shaped carry nothing: GPG signing adds -S to the commits this app makes and writes nothing to ~/.gitconfig, and a chip there would be the same confusion in a smaller font. The save modes are said rather than discovered: each block reads either Saved as you change it. or Nothing here is saved until you press Save. — one mode per block, in words, instead of a page where some fields kept themselves and others waited for a button with nothing to tell them apart. The identity's description said these values "sign your commits", directly above the block that actually signs them; it now says what they are, the name and email your commits are authored with. And the explanation of why the app has to go looking for git — the truncated PATH of an app launched from the Finder — folds away behind Why this app has to look for git: a diagnosis worth reading once and in the way every other time. The setting itself stays where it was. (#197)