Re: [PATCH v2 2/2] send-email: Support separate Reply-To address

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 17, 2018, 21:02 UTC
Message-ID: <xmqqzi5cqjur.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20180117180801.31049-2-chrissicool@gmail.com>

Christian Ludwig <chrissicool@googlemail.com> writes:

Show 17 quoted lines

> In some projects contributions from groups are only accepted from a
> common group email address. But every individual may want to recieve
> replies to her own personal address. That's what we have 'Reply-To'
> headers for in SMTP.
>
> Introduce an optional '--reply-to' command line option. Unfortunately
> the $reply_to variable name was already taken for the 'In-Reply-To'
> header field. To reduce code churn, use $reply_address as variable
> name instead.
>
> Signed-off-by: Christian Ludwig <chrissicool@gmail.com>
> ---
>  Documentation/git-send-email.txt       |  5 +++++
>  contrib/completion/git-completion.bash |  2 +-
>  git-send-email.perl                    | 18 +++++++++++++++++-
>  t/t9001-send-email.sh                  |  2 ++
>  4 files changed, 25 insertions(+), 2 deletions(-)

Thanks.

While merging this with other topics in flight on 'pu', there were minor merge conflicts, especially with np/send-email-header-parsing that ends at b6049542 ("send-email: extract email-parsing code into a subroutine", 2017-12-15) that attempts to refactor the code that reads the header lines. As there is *no* real change that benefits by the refactoring accompanying the topic, it was a bit hard for me to say if it is needless code churn or if it is a good refactoring.

I wonder if this change can be a good demonstration to measure the goodness of it. IOW, how would these two patches look if rebased on the result of merging b6049542 to today's 'master'? Would it make these two patches cleaner and easier to grok?