A four-pedal layout for comparing two code versions
Pedal Four is a wired controller with four foot inputs that can be configured for supported shortcut actions. When comparing code versions, use those controls to move through a comparison you already understand. The useful layout is a map of views and navigation, not a shortcut for deciding that one version is correct. Establish the revisions before reaching for the pedals.
Which two versions are being compared?
Name both sides explicitly in the review tool. A working file, staged changes and a committed revision can represent different states even when their names look familiar. The Git diff reference explains the comparison forms available in Git. Match the review interface to the question you are trying to answer.
Keep the revision or branch labels visible. If the tool refreshes after a new commit, check that the comparison still has the intended scope. A physical next-change control can make it easy to move through output while overlooking that its source has changed.
What could the four controls do?
Consider previous change, next change, focus the file list and return to the comparison pane. These are candidate actions, not universal shortcuts. Test the review application's own commands first and choose bindings supported by your hardware and configuration utility.
A separate focus action can make the route clearer than a macro that assumes the pointer is already over the correct pane. Avoid assigning a fixed sequence of clicks or typed commands to simulate a view the application cannot reliably address. The layout should make navigation predictable from ordinary starting states.
Where should staging and accepting changes belong?
Keep them outside the initial comparison profile. Staging a hunk, discarding a version and accepting an edit change the work rather than reveal it. They require checking the current file and selection. Physical separation may help you remember the distinction, but it does not replace that review.
If you later add a consequential action, label its exact outcome and preserve the application's visible checks. Do not call a pedal Next if it also accepts the current change. A reader of your legend should understand whether pressing it merely moves the view or changes repository state.
How do you evaluate the layout before relying on it?
Use a small known diff and navigate every change without modifying files. Start from the file list, code pane and another editor panel to see where focus matters. Check a held press for repeat behaviour. The Pedal Four product details describe the input hardware; a useful comparison profile is one you can verify in the specific review application.