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

You will finish with a quick, repeatable way to see the Git logical values that affect commits, editing, paging, new branch names and configuration files. This is a read-only check: it does not rewrite your repository or 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
Andy Dixon <[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. For the person recorded as the committer, query the corresponding logical variable.

$ git var GIT_COMMITTER_IDENT
Andy Dixon <[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. GIT_EDITOR follows this order: GIT_EDITOR, core.editor, VISUAL, EDITOR, then Git's compiled-in default. GIT_PAGER uses GIT_PAGER, core.pager, PAGER, then its compiled-in default. The sequence editor has its own first two choices, GIT_SEQUENCE_EDITOR and sequence.editor, before falling back to GIT_EDITOR.

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.

Checkpoint: confirm the values you meant to inspect

• 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/andy/.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. Some path variables 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=Andy Dixon <[email protected]> 1790226452 +0100
GIT_AUTHOR_IDENT=Andy Dixon <[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. 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

Do not use a blank-looking line as the only test: command substitution and pipelines can hide failures. Also avoid wrapping git var in sudo. Root's environment and configuration are a different context, so elevated execution can tell you about root's Git rather than the account that will perform the work.