Re: [PATCH] commit: add --committer option

[Patrick Steinhardt <ps@pks.im>]

On Mon, Nov 10, 2025 at 03:11:36PM -0500, Jeff King wrote:
> On Mon, Nov 10, 2025 at 06:01:57PM +0000, brian m. carlson wrote:
> 
> > On 2025-11-10 at 16:50:04, Phillip Wood wrote:
> > > On 09/11/2025 10:22, ZheNing Hu via GitGitGadget wrote:
> > > > From: ZheNing Hu <adlternative@gmail.com>
> > > > 
> > > >      This patch introduces the --committer option to git-commit, providing:
> > > >       1. Consistency with the existing --author option
> > > >       2. A more convenient alternative to environment variables
> > > >       3. Better support for automated workflows and scripts
> > > >       4. Improved user experience when managing multiple identities
> > > 
> > > What's the use case for the same person committing under different
> > > identities? We already have a config mechanism to set different identities
> > > for different repositories but I'm struggling to see why someone would want
> > > to create commits under multiple identities in a single repository. For
> > > scripts it easy enough to set the relevant environment variables if a tool
> > > wants to create commits under its own identity.
> > 
> > Someone who works on the same project under both their personal and
> > corporate identities.  For instance, me working on the Git project.
> > 
> > Some open source projects also require a CLA and you have to use a
> > particular address to match the one that's listed on the CLA.  For
> > example, Google requires an address with a Google account, so in the
> > hypothetical state where I was going to contribute to one of their
> > projects, I'd need to use a different committer identity with my Gmail
> > address.
> > 
> > I've also kept business logs in Git when I had a small business and I
> > might well need to log approving a profit distribution (with my
> > corporate address) and log accepting a profit distribution (with my
> > personal address).  Those would need separate digital signatures from my
> > two different email addresses.
> 
> Is a "--committer" option the best solution there, though? I'd think
> you'd want to set user.* in the repo-level .git/config (or using a
> dir-specific include) would be less error-prone.
> 
> That doesn't help for using two identities for the same repo, but in my
> experience it is easier to use two separate repositories for that to
> match the organization of the work (even if you may sometimes fetch
> between them).
> 
> I'm not totally opposed to the new flag, and in general I'd defer to
> people who say they find a new feature useful. I'm just having a hard
> time imagining a scenario where it's the best option.

The reason why I find it useful is mostly scripted uses. Sure, you can
already set environment variables there. But from my experience,
environment variables tend to be a significantly worse API compared to
command line options:

  - They are harder to discover in the manual page.

  - You don't have any "guarantees" that Git actually interprets them,
    as there won't be an error if you mistype the name.

  - Cause and effect may be detached with environment variables, but
    with command line options that's never the case.

So I myself would prefer using "--committer" over its accompanying
environment variable any point in time when I have a scripted use case
for it.

Patrick