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

From: Phillip Wood <[email-masked]>
Date: Tue, 11 Nov 2025 14:53:03 +0000

On 11/11/2025 06:54, Patrick Steinhardt wrote:
> 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 <[email-masked]>
>>>>>
>>>>>       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.

Yes, it strikes me as very inconvenient to have to specify "--committer" 
each time. I'd have though you'd either want to (i) set up an alias in 
which case you can start your alias with "-c user.name=..." or 
"!GIT_COMMITTER_NAME=...", or (ii) set GIT_COMMITTER_NAME in your shell.
> 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.

They're documented in the COMMIT INFORMATION section of the "git commit" 
man page, admittedly that comes after the options and examples but 
overriding the committer is a fairly niche requirement.

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

Playing devil's advocate even if you use "--committer" you still need to 
check the result to make sure there were no typo's in the committer info 
just as you would if you were setting GIT_COMMITTER_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.

I'm wary of cluttering the UI of one of our core porcelain command with 
options for use with scripting.

Thanks

Phillip