public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed
From: Jeff King <peff@peff•net>
To: ZheNing Hu <adlternative@gmail•com>
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>
Subject: Re: [PATCH] commit: add --committer option
Date: Tue, 11 Nov 2025 14:15:08 -0500	[thread overview]
Message-ID: <20251111191508.GA1907007@coredump.intra.peff.net> (raw)
In-Reply-To: <CAOLTT8RweGOmxNK=vKDv8w-8AJM7QUfLBw4WOKeY1EpSVeB6iQ@mail.gmail.com>

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.

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

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

  reply	other threads:[~2025-11-11 19:15 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
2025-11-12 16:11           ` ZheNing Hu
2025-11-11 13:42       ` ZheNing Hu
2025-11-11 19:15         ` Jeff King [this message]
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=20251111191508.GA1907007@coredump.intra.peff.net \
    --to=peff@peff$(echo .)net \
    --cc=adlternative@gmail$(echo .)com \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitgitgadget@gmail$(echo .)com \
    --cc=gitster@pobox$(echo .)com \
    --cc=phillip.wood@dunelm$(echo .)org.uk \
    --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