In Git, what determines which editor opens for a commit message, and how do you change it?

## When Git needs an editor at all Several commands hand you a file to fill in: `git commit` with no `-m`, `git commit --amend`, `git tag -a` without `-m`, `git merge` when it wants a merge message, `git rebase -i` for the todo list, and `git config --edit`. In every case Git writes a temporary file, launches an editor on it, waits for the editor to exit, and then reads the file back. That last sequence is the whole mental model, and it explains almost every problem people hit. ## The search order Git picks the editor from the first of these that is set: 1. `GIT_EDITOR` — environment variable, highest priority, ideal for one-off overrides and scripts. 2. `core.editor` — configuration value, subject to the ordinary scope cascade, so a repository can override your global choice. 3. `VISUAL` — a long-standing Unix convention for a full-screen editor. 4. `EDITOR` — the older, more general convention. 5. A compiled-in default when none of the above is set. `git var GIT_EDITOR` prints the resolved result, which is the fastest way to answer "why does *that* keep opening". Because `core.editor` is ordinary configuration, `git config --show-origin --get core.editor` will name the file it came from if the value is unexpected. ## Setting it `git config --global core.editor "<command>"` is the normal form. The value is interpreted as a shell command, so options are allowed and the temporary file's path is appended as the final argument. That appending is worth remembering: your command must be one that accepts a filename at the end. A repository-local `core.editor` is legitimate but rarely what you want — the editor is a property of the human, not the project. ## The blocking problem Many graphical editors, when a window is already open, pass the request to the running instance and exit immediately. Git interprets that exit as "the user finished editing", reads the still-unmodified template, sees no message content, and aborts with a complaint about an empty commit message — while your editor cheerfully displays the file you never got to save. The fix is always the same shape: configure the editor's option that makes the launched process wait until the file is closed. If a command does not offer one, wrap it in a small script that blocks. The symptom is unmistakable once you know it: the commit aborts instantly and the editor window opens a fraction of a second later. ## Scripted and non-interactive use In automation you want the prepared message accepted without a human. `GIT_EDITOR=true git rebase --continue` runs `true` as the "editor": it exits successfully, leaves the file untouched, and Git proceeds with whatever message was already prepared. This is far cleaner than trying to feed keystrokes to a real editor, and because `GIT_EDITOR` sits at the top of the search order it overrides whatever the user has configured. Conversely, if a CI job hangs, an editor waiting for input on a terminal that will never provide it is a prime suspect. ## The related pager setting Output paging follows the same layered idea with its own names: Git chooses `GIT_PAGER`, then `core.pager`, then `PAGER`, then its default. `pager.<command>` turns paging on or off for a specific command — `pager.branch = false` stops short branch listings from opening a pager — and `git --no-pager <command>` disables it for one invocation. Git also sets sensible default options for `less` when the environment does not specify any, which is why colour and short output behave well out of the box. Knowing the pager knobs matters mostly for scripting, where an unexpected pager blocking on a non-terminal is a classic hang. ## What interviewers are really checking This question is a small proxy for whether you understand that Git leans on the surrounding environment rather than reimplementing it: editors, pagers, shells and credential prompts are all delegated, each with a documented precedence chain and an environment-variable escape hatch at the top. Being able to name the chain, and to say how you would *verify* which entry won rather than guessing, is the whole answer.