Git Vertex VS Code Extension v1.35.0

Git Vertex VS Code Extension v1.35.0

Added

• Make your own theme. Settings › Appearance › Create a theme opens a drawer over the app, and the app is the preview: a theme is twenty-four seeds, everything else derives from them, and changing one repaints the whole window, graph included. Start from the theme in use or from an installed one; the validator's rules are shown live beside the seed they are about; an inspect mode answers the other question — click anything in the window and see which seed colours it, with a jump to that seed. A seed answers where it makes a real part of the colour — a third or more — so hovering text boxes the text, not the frame it tints by a tenth, and a pressed button is its accent, not the text mixed into it. Saving installs the theme through the same store and validator as one from the bank, and puts it in use; the file it exports is the bank's own format, and a pasted one loads. Local to the machine; sharing to the bank is the next step. The themes above it are a shelf now: every one, on two rows that slide sideways and fade in from the edge, with the bank's card standing still at their end. (#242)
• Git Vertex in the side bar. The view lives wherever VS Code lets a view live: the bottom panel it opens in, the primary side bar, the secondary one. Drag it to the activity bar, or run Git Vertex: Move to Side Bar and Move to Panel from the view's title menu or the command palette; an activity-bar icon carries the mark and waits, empty and invisible, until the view is put there. It is the same view with the same state wherever it goes — which is the whole point, and what the next entry is about.
• A narrow column fits. Below 640 px the panel changes shape instead of clipping. The rail narrows to 36 px and stays; the view a rail icon opens floats over the graph as a layer, closed by Escape or a press anywhere else, rather than taking a column the graph does not have. The details — the staging pane, a commit — go under the graph, with a splitter between them whose height is remembered, or replace it with a way back when the column is short as well. The toolbar keeps the branch and the sync actions with their counts, folds the rest behind a "⋯" menu, and gives the search field a row of its own; in a short column a button reveals it. At 300 px the old single row lost Undo, Redo, Settings and the search field off its right edge — nothing is cut off now, and the panel's own geometry check runs the column at 320 × 800 and 320 × 400 on every change.
• The terminal names commits, and they are links. A SHA, a branch, a tag or a range like main..feature printed in an integrated terminal — by git log, a test runner, a coding agent — is underlined on hover; a click shows the commit in the graph, brought forward wherever the view lives, or opens the comparison. A word is a link only when the repository has a ref of that name, and a run of digits is a number, not a commit.
• A commit named from outside is shown in the graph. The blame hover gains Show in Graph beside File History; Git Vertex: Show Commit in Graph in the palette asks for a SHA, a branch or a tag. The commit is selected and scrolled to; when it lies beyond the page the graph holds, the page grows to reach it the way the extended search reaches a hit, up to the same limit, past which its position is said instead — and a commit on no branch the graph shows says so too.
• The keyboard reaches the rows that matter. In the graph, h jumps to HEAD, u to its upstream, w to the working changes, Home and End to the ends of the page — plain letters, never a chord, and never while typing.
• The view's header says what is in it. The changed-file count is a badge on the view's title (and on the panel's tab while it is collapsed, the way the Source Control view counts), and the branch is the description beside it — wherever the view is, in the one place the webview itself cannot reach.
• A workspace with several repositories: the panel switches between them. The name in the toolbar becomes a picker when the workspace folders belong to more than one repository; choosing one puts it on screen, and the watchers, the editor tab, the status bar and the rebase detection follow it. The choice is remembered per workspace. The panel used to show the first folder's repository and nothing let it show another.
• The graph names the stretch of time it is scrolled to. A small band at the top right of the graph reads Today, Yesterday, This week, This month or August 2026 for the first visible row, and a hairline marks where one stretch ends and the next begins — so a long scroll down a tall column still says when. It appears once the page spans more than one stretch; Date bands in the graph header's menu and in Settings › Graph turns it off. Both products.
• A minimap of the activity above the panes. A block of its own, under the toolbar and as wide as the side pane, the graph and the details together, draws the loaded history day by day — commits, or lines changed — newest on the left, with HEAD and its upstream on the top edge, ticks for local branches and stashes (remote branches and tags on request), the stretch the graph has on screen, and the days the search matched. Hover a day for its date, its count and its refs; click it and its commit is selected and scrolled to; drag across it to zoom, double-click or Exit zoom to come back; the wheel over it scrolls the graph; the gap under it is its handle, and the height it is dragged to is kept. It is built from the rows the graph holds, so a day on it is always a day the graph can show, and Load more widens it. It hides from its own menu, the toolbar's switch, Minimap in the graph header's menu or Settings › Graph, and stays hidden; the desktop's toolbar has a Minimap switch of its own. Both products.
• A Welcome page, once. A fresh install opens a page that says what the extension does and where, in six cards — the graph where you want it, the changes and the commit, blame in the editor, the terminal and the editor reaching the graph, the model, the look — each with a gesture that runs the thing rather than describing where to find it. An update keeps opening What's new instead; Git Vertex: Welcome reopens the page. Git Vertex: Open Panel Settings opens the panel's own settings page from anywhere.
• The graph can follow the cursor. A switch in the toolbar (the eye), or Git Vertex: Toggle Follow Cursor: on, the commit of the line under the cursor — its blame — is selected in the graph as the cursor moves, quietly: no focus taken, nothing said when the commit is off the loaded page, nothing for a line not committed yet. Off, the graph keeps what you selected. The setting is remembered.
• The overview is a home. The rail's first view answers "where am I, and what is next" in one place. The card of the current branch gains its issue, its pull request — or the door to one — and where it stands against the branch it will merge into (3 commits behind main · 1 ahead), and offers the one state action that is true: publish, pull or push, the rows the staging pane's empty state already computed, now where the branch is. Under it, Recent: the local branches whose tip moved within a timeframe (a day, a week, a month — remembered), newest first, each saying when, how far from its upstream, and which pull request it carries; a click shows the branch in the graph, a double-click switches to it. Then Waiting on you: how many pull requests need your review, how many of yours have changes requested, how many are approved — three searches the API already answered. Then what to start: an issue, a branch, a worktree, a stash. Every branch row now carries the date of its tip, from git's own for-each-ref, in one field more of the same process — both products.
• A file's history can follow the editor. The File History tab gains a switch, Follow editor: pressed, the tab shows the history of whatever file the editor moves to, inside the tab's repository, and retitles itself; released, it stays on the file it is on. A history asked for a file the following tab already reached lands on that tab rather than beside it.
• Who works here. The overview gains a Contributors section — the authors git's own shortlog counts, most commits first, merges left out, across every branch — and a row narrows the graph to that author; the same row again widens it back. The search field learned the operator behind it: author:name matches who wrote the commit and nothing else, where a bare word still matches the message and the hash too. Both products; the git call is one function in the shared core, run by both.
• A panel with no repository says so, and offers the doors. The open folder is not a repository, or no folder is open: the centre no longer shows a graph with "no commits yet" but names the situation and offers what fits it — Initialize Repository when a folder is open, the way VS Code's own Source Control view does; Open Folder… and Clone Repository… when none is — every one of them VS Code's own, run from an allow-list. Initialising is noticed: the panel looks again and fills in.
• Step through a file's revisions from the editor's title bar. Open Changes with Previous Revision on a working file compares it with HEAD while it is modified, and with the commit before the last one that touched it once it is clean; from a revision document it goes one commit further back, and Open Changes with Next Revision one forward, up to the working file again. A revision document also offers Show Revision Commit in Graph. The file's own history is the chain, so a file touched once a year steps once a year.
• The status bar opens the panel. The branch in the status bar is the most visible door to the extension, and it launched the desktop app — which is not always installed. It shows the view now; Open in Git Vertex still hands off to the desktop from the toolbar and the menus.
• A short panel is flush. Below 340 px of height the cards' gap goes, whatever the layout setting says: sixteen pixels of a two-hundred-pixel panel belong to the staging pane, not to the frame. The geometry check had been failing at 194 px since the frame arrived, and nobody had run it.
• The panes are cards. The side panel and the graph sit as rounded cards on a frame, set apart by a gap rather than by a line — the rail and the compact toolbar are the frame, the way VS Code's own activity bar is. It is the default; Settings › Appearance › Layout offers Flush, the edge-to-edge rendering the panel had, and compact density takes the frame in with everything else. (#240)

Fixed

• A menu closes when you do something else. It closed on a press elsewhere only when that press produced a mousedown — and a splitter cancels its press to keep the drag from selecting text, so a press on the gap under the minimap, or between the panes, left an open menu up. Presses are caught before any control can cancel or keep them now, and a click in the editor around the panel, which the webview never hears, closes it too. The minimap's options button toggles its menu: a second press puts it away.
• A submenu near the window's right edge opens on the left. A submenu always opened to the right of its row, so one near the right edge — the minimap's Markers, a submenu of the toolbar's ⋯ in a narrow column — was drawn past the edge, unseen and out of reach. With no room on the right it opens on the left now, and is lifted when it would run past the bottom. The menu itself is clamped by its real size: it opens with a small scale-in, and a size read on that first frame left a menu opened against the right edge a few pixels over it, its border cut off.
• One Escape closes one thing. With a menu open over the graph — the staging pane's Options, say — Escape closed the menu and cleared the selection, taking the pane with it. The graph now leaves the key to any open menu, drawer or dialog, not only to its own.
• The staging pane's title no longer wraps in a narrow column. Under 340 px "Working Changes" reads "WIP", the word the graph's row already uses for the same thing, with the full name on hover.
• The native commit menu answers in the webview it was opened from. The graph's right-click menu is VS Code's own, and its reply travels through the extension host, which relayed it to the last webview it had created — with the panel and the editor tab both open, a right-click in one could act in the other. The host follows the pointer now.
• The working-tree row counted a file twice. Stage everything, then touch one of the files again: git status lists it in both columns, the staging pane rightly shows it twice — once to commit, once still to stage — and the number on the WIP row and in the pane's header added the two lists, so two files read as three. The count is over files now, on the row, in the header and in the N of M staged badge. (#232)
• A branch name in the graph opened two menus. A right-click on a branch name in the pill under a commit opened the branch's menu, then went on to the commit row underneath — whose menu, in VS Code, is the editor's native one. Two menus, one over the other, and the native one is the one that stays. The right-click stops at the name now, as it always did on the branch chips of the column layout. (#233)
• A theme's accent was the outline of every control. The panel shares the app's themes, and the one border seed was read from a VS Code theme's structural separators first — panel.border, the line above the terminal, which Dracula paints in its purple on purpose — and it lands on inputs, chips, rows and cards alike. It is read from the theme's own separators now — the section line, the panel edge — composited over the canvas when the theme writes them with an alpha; a border that is a colour of its own, or that sits on the far side of the canvas from the text where nothing can see it, is derived instead: the canvas a step toward the text, which is the light grey VS Code itself draws where a theme sets nothing. Fifteen of the thirty-two built-in themes change their line — Dracula's purple becomes a quiet grey-blue — and the validator refuses a border that is not its canvas a shade off, measured in Oklab's chroma plane: the same rule the bank is generated against, so nothing served is refused at the door.
• A theme's accent is the colour it marks things with, not its button. The accent seed was read from the link colour, then the button — and Dracula's button is its grey current line, so the commit button, the links and every accent in the app were grey while its pink went, by accident, to the model's colour. The accent is now the colour a theme uses most where VS Code marks the user's action or attention: the button, the link, the activity-bar badge, the progress bar, the focus ring, the active tab and panel title, the remote item — greys not voting. The model's colour is the theme's second such colour when it has one of a clearly different hue, Dracula's purple beside its pink; otherwise the theme's own violet, or the lane nearest it. Twenty-two of the thirty-two built-in themes change their accent — Dark+ and Light+ get VS Code's blue back, Catppuccin its mauve — and 516 themes of the bank stop having a grey one.
• The graph's lanes start at the accent, and no lane is a diff colour. An imported theme's ten lanes are samples around its hue wheel, and the wheel began at red: the branch you are on, first drawn, was red in Dracula — its removed lines red, to the byte, with an added-lines green three lanes over. The wheel now starts at the hue nearest the accent, as the default theme's does, so the current branch carries the theme's colour; and a lane that reads as one of the four semantic colours is left out while six colours remain, below which two neighbouring branches would share one, which is the worse reading. Fewer than ten are walked in order and wrap. Every built-in theme's lanes change. (#237)

---

Installe le VSIX directement :

code --install-extension git-vertex-1.35.0.vsix

Ou cherche Git Vertex dans le Marketplace VS Code.

🔗 VS Code Marketplace
🔗 Open VSX