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

> 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.

>    - 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.