From: ZheNing Hu <adlternative@gmail.com>
Date: Wed, 12 Nov 2025 16:37:37 GMT
Subject: Re: [PATCH] commit: add --committer option
Message-ID: <CAOLTT8S4D5M8uzzx75p_kAr5wsW3JyhVEQg=FW4ww+aYfTnk0g@mail.gmail.com>
In-Reply-To: <20251111191508.GA1907007@coredump.intra.peff.net>

Jeff King <peff@peff.net> 于2025年11月12日周三 03:15写道：
>
> On Tue, Nov 11, 2025 at 09:42:38PM +0800, ZheNing Hu wrote:
>
> > > 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.
> >
> > Sometimes it's because I forgot to configure the repository-level git user
> > config and started development first. Only when I tried to correct the
> > committer did I feel the pain.
>
> OK, this workflow does make sense to me. Fixing up an earlier mistake is
> inherently a one-off thing, and a command-line option is more ergonomic
> than using the environment variables.
>
> Two small thoughts:
>
>   - I suspect what you'd usually want there is for the committer and the
>     author to match. We have --committer-date-is-author-date for rebase,
>     and conceptually I think something like --committer-is-author would
>     do what you want here. But obviously it's less flexible, and I don't
>     know if it's that much easier to use.
>

Well, to be honest, I don't really like this kind of -A --BaseA option style.
On the contrary, -A -B is actually simple and easy enough for me
(or more symmetrical). However, it's true that git rebase probably
doesn't have --author and --committer options. Perhaps this is also
a pain point, or maybe something to look into for potential future
contributions.

>   - Because it's easy to make such mistakes, when you override the
>     author (so that it doesn't match the committer), git-commit prints
>     an extra "Author:" line in the output to make that more obvious.
>     Should we do the same with committer when you've overridden it?  We
>     already do print "Committer:" when the ident was guessed from system
>     info, but I wonder if it would make sense to print when it was
>     forced. I dunno. I guess the time you most need the hint is when you
>     meant to use --committer and --author together, but only used
>     --author. But I don't know how Git would infer that case (versus the
>     normal case of you applying someone else's work and crediting them
>     with --author).
>

Ah, you have a point. Perhaps the Commit should also be output,
though it might be trivial (if you hadn't reminded me, I wouldn't have even
noticed that git commit outputs Author when using --author).

> I'm not sure if either is a useful direction, but they seemed
> sufficiently not-dumb for me to at least type them out. ;)
>
> -Peff