Entering a reference in the Show wizard can discard it and send the wizard back to the command menu
Summary
In the show flow, the "Enter a reference or commit SHA" step offers only Back and Cancel until the typed value has been validated against git. Back is the pre-selected item and directive items are always shown, so typing does not filter it away. An Enter pressed before validation finishes activates Back: the wizard navigates back to its previous step, the typed reference is discarded, and nothing says why.
Impact
Enter is the only way to submit a reference on this step, and for the window in which the value is still being validated it does the opposite of submitting — it leaves the flow. What the user typed is gone, they land on the command menu, and there is no message, so the natural reading is that the reference was rejected or that the wizard glitched.
The same directive-only state is reachable beyond show: log, merge, rebase, reset and search use the same step and fall into it whenever their commit list comes back empty, and the branch and tag pickers do the same when a repository has none. show is the only caller that is always in that state, because it enters the step with a deliberately empty list.
Validation
Where the window comes from. The step builds its items as Back (pre-selected) and Cancel when it has no commits to list. The typed value is validated asynchronously — a reference check followed by a commit lookup — and only when both finish are those two items replaced by the resolved commit. Validation restarts on every keystroke and is not debounced, so the window opens at the last character typed, not the first.
Why typing does not dismiss Back. Directive items are created with alwaysShow, so the quick pick keeps showing them no matter what is typed, and Back stays the active item that Enter will accept.
Measured window. Against a 6-commit fixture repository, the item list takes 32–72 ms (median 37 ms) to flip from the directives to the resolved commit with nothing else running. Under four concurrent editor instances the same measurement is a median of 807 ms with a maximum of 1297 ms, over 20 runs.
Observed end state. When Enter lands inside the window the quick pick is showing the root command list — branch, cherry-pick, fetch, history, merge, … — with the placeholder Choose a command, and it stays there. The wizard is alive and responsive; it simply is no longer in the show flow.
Not measured. Whether a person beats the window on a large repository, where both git calls take longer, and on a cold cache. The numbers above come from a small fixture, so they are a lower bound on the window rather than an estimate of how often someone hits it. The report is about Enter performing Back on a free-text step at all — a correct step would either ignore Enter until the value resolves or submit the value.
Risk
- Widening the window is what makes it visible, so any change that makes reference validation slower — a larger repository, a cold cache, a slow filesystem — makes this more frequent rather than less.
- A fix that simply removes the pre-selection would leave Enter doing nothing during the window, which is better but still silent; the value the user typed should survive it.
- This was found from the other side: the same race made an E2E spec fail 20–30% of the time under load (#5775, fixed in #5854 by waiting for the value to resolve before submitting). The test now works around it, so the suite will no longer surface regressions here.
Source: gitkraken/vscode-gitlens