Christian Ludwig <chrissic...@googlemail.com> writes:
> 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 <chrissic...@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?
