Re: [PATCH v2] builtin/ident: add new 'ident' command

From: Jeff King <peff@peff.net>
Date: Sep 1, 2026, 04:39 UTC
Message-ID: <20260901043944.GA1074757@coredump.intra.peff.net>
In-Reply-To: <pull.2388.v2.git.git.1788220746663.gitgitgadget@gmail.com>

On Mon, Aug 31, 2026 at 11:59:06PM +0000, Andrew Pleeter via GitGitGadget wrote:

Show 7 quoted lines

> While existing plumbing commands like 'git var' and 'git config' expose
> individual pieces of identity and configuration, discovering what identity
> and signing key will actually be attached to a new commit requires multiple
> independent queries and manual correlation. 'git config' only reads raw
> values without performing environment overrides or GECOS detection, while
> 'git var' returns full ident strings with timestamps without exposing
> commit signing status.

This is just my gut reaction, but: would it be simpler to teach git var to provide those broken-down pieces than to introduce a whole new command?

This works now:

  git var GIT_COMMITTER_IDENT

but why not:

  git var GIT_COMMITTER_NAME
  git var GIT_COMMITTER_EMAIL
  git var GIT_COMMITTER_DATE

Those are well-known names already; they're what we use for reading in the broken-down values from the environment. And likewise for GIT_AUTHOR_*.

Let's see what else is in your feature list:

> 'git ident' provides a unified command with additive, composable options:
>   - Identity scope selectors (-a / --author, -c / --committer) choose
>     which identities to format (defaulting to both when neither is specified).

I think that works by switching between the two var families above.

>   - Component selectors (-n / --name, -e / --email) choose which parts
>     to format (defaulting to full 'Name <email>' when neither or both are
>     specified).

We don't allow mix-and-match here (nor even multiple values!), so you'd have to do:

  ident="$(git var GIT_AUTHOR_NAME) <$(git var GIT_AUTHOR_EMAIL)"

I think it would be reasonable for git-var to accept multiple values and output them one per line (or with NULs via "-z"). That doesn't really make things easier in shell, but it might help scripts in other languages.

We _could_ go as far as providing a format language like we do in for-each-ref, etc, where we offer to shell-quote. And then you can do:

  eval "$(git var --shell-quote --format='
		name=%(GIT_AUTHOR_NAME)
		email=%(GIT_AUTHOR_EMAIL)
	')"

but IMHO that is probably going too far. It sometimes lets you simplify shell use of the tool at the expense of a weird and complicated interface (I kind of which we didn't have it in for-each-ref).

>   - -v / --verbose prepends 'Author: ' or 'Committer: ' role labels.

Seems like something that git-var might benefit from, too.

>   - -s / --signing-key resolves and outputs the commit signing key.

Likewise, this feels like it should be a git-var entry.

>   - --porcelain produces machine-readable key-value pairs.
>   - -z / --null terminates output records with NUL bytes.

Likewise.

My main feeling on suggesting this is that:

  1. We already have a lot of commands, and this one feels very
     specialized.

  2. Most of these suggestions could make git-var better for reading
     idents _and_ for reading its other variables.

-Peff