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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

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

Not very much, at least to me.  Fixing up an earlier mistake may be
one-shot thing but it is to correct multiple commits in one go,
which would be error prone if you do so with "git commit --option".
Either "fast-export | fast-import" pipe, or "git rebase" (which this
patch does not give --committer option, but it already knows how to
honor existing environment variables) would be used for that, no?

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

I am not sure how the user experience of this would look like.

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

Yup, guessing based on what you did _not_ give is always a hard task
for any tool ;-).

> 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