Git Manager: History and Details
Understand how Git Manager represents uncommitted changes, commit history, refs, detail workspaces, and the new menu-driven history controls in Basic and Advanced view.
History is split between now and already committed
The experimental Git Manager deliberately keeps the working tree and commit history in one timeline. That means your current edits, your recent commit story, your branch refs, and your tags can be reasoned about in one place instead of making you jump between separate Git views.
Switch to Basic view
Start in Basic view so you can understand the commit list first before the next step contrasts it with the richer Advanced layout.
Basic view keeps history inspection lean
Basic view is active here in the history list. It keeps the reading flatter and easier to scan: commit subjects, relative time, and a lighter visual treatment until you deliberately ask for more branch structure from the actions & options menu.
Basic mode still has reading controls in the actions & options menu
Use Next here to open the real actions & options menu while Basic is still selected. Open it when you want just a little more context without leaving Basic. This is where Refresh lives, where Fetch appears when remotes exist, and where the Show submenu lets you turn the graph and tags on or off while keeping the simpler Basic layout.
Basic keeps only the extra structure you ask for
This is the real Basic actions & options menu. Refresh redraws the repository view, Fetch appears when a remote exists, and Show is the small reading-control group for Basic mode. Inside that Show submenu, the toggle items for Commit Graph and Tags let you add or remove just the structure you need while staying in Basic.
Return to the history list
Close the open menu so the history list becomes the active surface again. That reset matters because the next step deliberately switches the lower workspace back to the live working tree instead of leaving attention on the previous menu state.
Uncommitted Changes anchors the current working tree
The pinned Uncommitted Changes row at the top of the list switches the detail workspace from recorded history to the current working tree. In Demo Projects HQ, that workspace lists the files that are modified, deleted, renamed, or still untracked right now. This is the row that answers the practical question: what would go into the next commit?
The current file list uses checkbox selection for staging
The file list underneath is a wui-list running in checkbox selection mode. Each row is a current file, not an old snapshot. Checkboxes let you decide exactly which files should be staged for the next commit, while the status icons tell you why the file is here: added, modified, renamed, deleted, or conflicted.
The preview toolbar controls batch review before you commit
When Uncommitted Changes is selected, the preview area exposes batch tools for the working tree. Select All and Select None change the staged selection quickly, while Discard All is the destructive escape hatch for throwing away the current working tree. This toolbar only belongs to the uncommitted workspace, because a past commit is something to inspect, not stage.
The commit box turns the reviewed selection into a snapshot
The commit message box belongs to the same uncommitted workspace. After you trim the staged selection to the files you want, describe the change here and create the next snapshot. The important habit is order: review the files, refine the selection, then write the message that matches exactly what is being committed.
Switch to Advanced view
Switch to Advanced view when you need more context around a selected commit, because the next details make more sense there.
Advanced view adds graph context before deep inspection
Advanced view is active here in the history list. The same commits now carry graph lines, refs, and tags so you can inspect branch movement and merge placement with the context already visible.
Advanced history shows refs and commit shape at the same time
With Advanced selected, the history list becomes more than a sequence of commit messages. Branch refs, tags, and graph structure sit alongside the commits so the next inspection steps happen with branch context already visible on screen.
Advanced menu controls decide how much history you see
Use Next here to open the real actions & options menu for Advanced view while the selected Advanced button is still on screen. In Advanced mode, this menu can switch between all history and the current branch, expose toggle-driven View and Show submenus, trim the graph, and reorder commits.
Advanced history controls answer different reading questions
This is the real Advanced actions & options menu. The View submenu changes the history scope between the whole repository story and just the current branch. The Show submenu controls toggle items such as Commit Graph, Tags, First Parent Only, and Decorated Commits Only, with checkmarks showing the active reading layers. Order changes how the same commit set is arranged, so you can prefer a chronological read or a cleaner graph-oriented read before you inspect individual commits.
Return to commit history
Close the open menu so the history list becomes the active surface again. That reset matters because the next step deliberately reselects a recorded commit and turns the lower workspace from menu context back into commit inspection.
A commit row opens the recorded snapshot details
A real commit row below Uncommitted Changes switches the detail workspace from commit preparation to commit inspection. The preview shows the recorded message, author, date, and totals for that snapshot, so the question changes here from what will I commit next to what exactly was committed at this point in history?
The summary strip explains the shape of the selected commit
At the top of the commit preview, Git Manager summarizes what kind of change set this commit contains. Those totals tell you whether the snapshot mostly created files, modified existing work, removed code, or renamed paths. It is the quickest way to judge the scope of a commit before opening the file rows one by one.
Committed files are shown in a read-only inspection list
The committed file list is another wui-list, but this one is for inspection instead of staging. Each row represents a file captured by the selected commit. In Advanced mode, the rows also expose insertion and deletion counts, so you can distinguish a tiny focused edit from a larger refactor before you even open a diff.
Context actions turn history into a working tool
Use Next here to select a real commit row and open the real history action menu so the branch, tag, recovery, and commit operations are visible on the following step.
The commit menu is the practical history toolbox
This is the real commit context menu on the selected history row. The direct history actions are Create Branch, Create Tag, Revert this commit, Checkout this commit, and Reset to this commit. If the selected snapshot already carries branch or tag refs, those ref labels appear here as submenu entries so ref-specific actions stay attached to the exact commit that exposed them.
Attached branch and tag labels open a second layer
When the selected commit already carries a branch or tag ref, the ref label itself becomes a submenu entry in the context menu. That keeps branch-specific or tag-specific actions attached to the ref you were already looking at instead of mixing them into one flat list.
Ref submenus explain what you can do to that exact branch or tag
A branch-ref submenu can offer checkout, merge into main, merge main into that branch, rename, delete, and copy branch name. A tag-ref submenu stays narrower: checkout, rename, delete, and copy tag name. The important pattern is that Git Manager keeps those ref actions attached to the exact label you opened, not hidden behind a generic branch dialog.
Stay in Advanced view
Reapply Advanced view first so the file-level history explanation starts from the richer commit context it depends on.
Changed files have their own history actions
The two detail lists support different kinds of decisions inside the lower workspace. In the Uncommitted Changes workspace, file rows help you inspect, discard, or resolve one current file at a time. In commit inspection, file rows help you diff, compare with HEAD, or check out one file from that past snapshot. The manager keeps those actions file-sized so review and recovery do not always require a branch-sized operation.
Return to the uncommitted row
Reselect the pinned Uncommitted Changes row first so the next step can open its smaller working-tree context menu instead of a commit menu.
The pinned Uncommitted row has its own smaller context menu
Right-clicking the pinned Uncommitted Changes row does not show branch or commit recovery actions, because this row represents the current working tree rather than a recorded snapshot. Its context menu is intentionally small and destructive: Discard All Changes is the repository-wide throw-away action for the current working tree, not a history rewrite command.
Continue with the next Git decision
Once the history model is clear, continue with the area that normally depends on it: recovery, branches, or remotes.
