Design a shortcut layer for reading Git diffs

KM16 Macropad offers enough separate keys to make a physical map of a code-review workspace. For reading Git diffs, begin with the views you need rather than commands that change the repository. A good review layer helps you find evidence: which files changed, what the surrounding code does, and whether you are looking at staged or unstaged work.

Which comparison are you actually reading?

Choose the comparison before mapping navigation. A working-tree diff, an index diff and a comparison between revisions answer different questions. The Git diff manual describes these forms. Put the comparison's name somewhere visible in your review tool so a shortcut cannot make two different scopes look identical.

Write a short review route: changed-file list, selected change, surrounding file, relevant test. This route is more useful than assigning a key to every Git command you know. If you cannot explain why you visit a view during a real review, leave that position unused until a need appears.

Which navigation deserves a dedicated key?

Start with actions that keep you in the review: opening the file list, advancing to another change, going back and finding a symbol. Use the review application's own documented commands when it exposes them. A key that changes focus reliably is often more useful than a macro that assumes the pointer is already in the correct pane.

Avoid attaching a return key to the end of a typed command merely to make the sequence feel complete. A changed prompt or terminal state can turn that convenience into an unintended action. Where possible, bind a named application command rather than injecting text into an arbitrary active field.

How should you separate reading from changing code?

Place inspection commands together and keep repository-changing actions outside the first review layer. Staging a hunk, discarding a change and committing are decisions, not steps required to see the next line. They can stay on the normal keyboard while you learn whether the navigation layer helps.

If you later add an action key, make its label explicit and preserve the application's confirmation or preview. Colour and physical distance are useful reminders, but neither replaces checking the current file and scope. The keypad cannot judge whether the agent's output is correct.

How do you test the layout on a real review?

Use a small change you understand and complete the route without touching repository state. Note any moment where you still reach for the mouse because the key's destination is unclear. Adjust those locations before filling spare positions. The KM16 Macropad needs configuration; the practical benefit comes from a review route you can explain and repeat.