From: Phillip Wood <phillip.wood123@gmail•com>
To: Patrick Steinhardt <ps@pks•im>, Jeff King <peff@peff•net>
Cc: "brian m. carlson" <sandals@crustytoothpaste•net>,
phillip.wood@dunelm•org.uk,
ZheNing Hu via GitGitGadget <gitgitgadget@gmail•com>,
git@vger•kernel.org, Junio C Hamano <gitster@pobox•com>,
ZheNing Hu <adlternative@gmail•com>
Subject: Re: [PATCH] commit: add --committer option
Date: Tue, 11 Nov 2025 14:53:03 +0000 [thread overview]
Message-ID: <f7a9bf6d-d723-437f-badd-517fbf47d945@gmail.com> (raw)
In-Reply-To: <aRLdsu-MUgPPdIgX@pks.im>
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 <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.
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
next prev parent reply other threads:[~2025-11-11 14:53 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-09 10:22 [PATCH] commit: add --committer option ZheNing Hu via GitGitGadget
2025-11-10 9:24 ` Patrick Steinhardt
2025-11-10 14:17 ` ZheNing Hu
2025-11-10 17:38 ` Junio C Hamano
2025-11-11 13:19 ` ZheNing Hu
2025-11-10 16:50 ` Phillip Wood
2025-11-10 18:01 ` brian m. carlson
2025-11-10 20:11 ` Jeff King
2025-11-10 22:06 ` Junio C Hamano
2025-11-11 6:54 ` Patrick Steinhardt
2025-11-11 14:53 ` Phillip Wood [this message]
2025-11-12 16:11 ` ZheNing Hu
2025-11-11 13:42 ` ZheNing Hu
2025-11-11 19:15 ` Jeff King
2025-11-11 20:16 ` Junio C Hamano
2025-11-11 21:33 ` Jeff King
2025-11-11 21:58 ` Junio C Hamano
2025-11-11 22:23 ` Jeff King
2025-11-12 16:51 ` ZheNing Hu
2025-11-12 16:48 ` ZheNing Hu
2025-11-12 16:46 ` ZheNing Hu
2025-11-12 16:41 ` ZheNing Hu
2025-11-12 16:37 ` ZheNing Hu
2025-11-11 13:01 ` ZheNing Hu
2025-11-11 14:38 ` Phillip Wood
2025-11-12 15:58 ` ZheNing Hu
2025-11-12 17:24 ` Junio C Hamano
2025-11-15 5:29 ` ZheNing Hu
2025-11-16 1:06 ` Junio C Hamano
2025-11-17 15:06 ` ZheNing Hu
2025-11-16 22:12 ` Matej Dujava
2025-11-17 14:27 ` Phillip Wood
2025-11-17 15:18 ` ZheNing Hu
2025-11-17 15:15 ` ZheNing Hu
2025-11-10 16:56 ` [PATCH v2] " ZheNing Hu via GitGitGadget
2025-11-10 19:22 ` Junio C Hamano
2025-11-10 19:29 ` Junio C Hamano
2025-11-11 13:36 ` ZheNing Hu
2025-11-11 15:40 ` Junio C Hamano
2025-11-12 16:23 ` ZheNing Hu
2025-11-12 16:55 ` [PATCH v3] " ZheNing Hu via GitGitGadget
2025-11-12 18:56 ` Junio C Hamano
2025-11-15 6:33 ` ZheNing Hu
2025-11-15 15:43 ` [PATCH v4] " ZheNing Hu via GitGitGadget
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f7a9bf6d-d723-437f-badd-517fbf47d945@gmail.com \
--to=phillip.wood123@gmail$(echo .)com \
--cc=adlternative@gmail$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=gitgitgadget@gmail$(echo .)com \
--cc=gitster@pobox$(echo .)com \
--cc=peff@peff$(echo .)net \
--cc=phillip.wood@dunelm$(echo .)org.uk \
--cc=ps@pks$(echo .)im \
--cc=sandals@crustytoothpaste$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox