Use git var to Inspect Git's Identity, Editors and Paths

Run git var when a commit shows the wrong author, or a script needs to know which editor Git will actually open. It is a read-only lookup of the logical values that drive commits, editing, paging, new branch names and configuration files: nothing here rewrites your repository or your Git configuration.

Allow about five minutes. You need Git installed and, for repository-specific values, a directory inside a Git working tree. Nothing here requires elevated privileges. The examples were checked with Git 2.43.0 on Linux; the installed git-var(1) page identifies that version.

1. Confirm the command and your starting point

Run the version check first. It separates a missing command from a surprising value later in the guide.

$ git --version
git version 2.43.0

Change /path/to/repository below to a real checkout, then run the identity query from there.

$ cd /path/to/repository
$ git var GIT_AUTHOR_IDENT
Alice Example <[email protected]> 1790226452 +0100

Your name, address, timestamp and offset will differ. The value is Git's current author identity, not necessarily a record of the author of the last commit. Query the corresponding logical variable for the person recorded as the committer.

$ git var GIT_COMMITTER_IDENT
Alice Example <[email protected]> 1790226452 +0100

These commands read configuration and environment state. If the identity is wrong, stop here and inspect it with git config; do not treat git var as a configuration editor.

2. Check which editor and pager Git will invoke

Git's editor and pager values are command text. Git passes them to a shell when a command needs them, so treat output as executable configuration and do not paste an unrecognised value into a shell script without checking its source.

$ git var GIT_EDITOR
cat
$ git var GIT_SEQUENCE_EDITOR
cat
$ git var GIT_PAGER
cat

The exact output depends on your environment. Each variable has its own fallback order:

• GIT_EDITOR follows GIT_EDITOR, then core.editor, then VISUAL, then EDITOR, then Git's compiled-in default.
• GIT_SEQUENCE_EDITOR checks GIT_SEQUENCE_EDITOR and sequence.editor first, before falling back to GIT_EDITOR.
• GIT_PAGER follows GIT_PAGER, then core.pager, then PAGER, then its compiled-in default.

A common distraction is checking EDITOR and assuming that is what Git will use. A repository configuration or a higher-priority environment variable may win. Compare the layers without changing them:

$ env | grep -E '^(GIT_EDITOR|GIT_SEQUENCE_EDITOR|GIT_PAGER|VISUAL|EDITOR|PAGER)=' || true
$ git config --show-origin --get-regexp '^(core\.editor|core\.pager|sequence\.editor)$' || true

If the first command prints an unexpected value, clear that variable only for a test shell, for example env -u GIT_EDITOR git var GIT_EDITOR. Undoing that test means closing the shell or restoring the variable; no repository state was changed.

• Author and committer identities are plausible for this checkout.
• Editor and pager output names a program or command you recognise.
• You have checked environment overrides before editing configuration.

3. Inspect the default branch and Git paths

These logical variables are useful when a script must report how Git was built or where it expects supporting files. They are information only. A printed path may not exist, and that does not by itself mean the query failed.

$ git var GIT_DEFAULT_BRANCH
master
$ git var GIT_SHELL_PATH
/bin/sh
$ git var GIT_CONFIG_GLOBAL
/home/alice/.config/git/config

GIT_DEFAULT_BRANCH is the name Git uses for the first branch in a newly initialised repository; it does not rename an existing branch. GIT_SHELL_PATH identifies the POSIX shell used by Git commands that need one. The configuration path variables report system and per-user locations, including paths selected through environment settings, and some can contain several newline-separated entries ordered from highest to lowest priority.

Use a loop when you want a compact diagnostic report. Keep each variable as a separate argument so an empty value can be distinguished from a failed shell pipeline.

$ for name in GIT_DEFAULT_BRANCH GIT_SHELL_PATH GIT_CONFIG_SYSTEM GIT_CONFIG_GLOBAL; do
    printf '%s: ' "$name"
    git var "$name" || printf '<unset>'
    printf '\n'
  done

On this Git build, a known path query prints its configured location even when the file is absent. If an environment variable disables that location, Git does not print it. That distinction matters in portable diagnostics: report the value first, then test a path with ordinary tools if you need to know whether a file exists.

4. List all logical variables when debugging

Use -l for a broad snapshot. It includes Git's logical variables and the variables in the repository's .git/config.

$ git var -l
GIT_COMMITTER_IDENT=Alice Example <[email protected]> 1790226452 +0100
GIT_AUTHOR_IDENT=Alice Example <[email protected]> 1790226452 +0100
GIT_EDITOR=cat
GIT_SEQUENCE_EDITOR=cat
GIT_PAGER=cat
GIT_DEFAULT_BRANCH=master

The complete list varies with configuration, so use a particular query in scripts when you need a stable interface. The listing feature is deprecated for configuration inspection: use git config list or git config --list for configuration data instead, and do not parse the full -l output as if every line were a normal configuration key.

5. Handle missing values and exit status

git var exits with status 1 when the requested variable has no value. Check that status explicitly when using it in automation.

$ if value=$(git var GIT_EDITOR 2>/dev/null); then
    printf 'Git editor: %s\n' "$value"
  else
    printf '%s\n' 'Git editor has no value' >&2
    exit 1
  fi