From: Junio C Hamano <gitster@pobox.com>
To: Christian Couder <christian.couder@gmail.com>
Cc: Christian Couder <chriscool@tuxfamily.org>, git <git@vger.kernel.org>
Subject: Re: [PATCH 1/3] trailer: add a trailer.trimEmpty config option
Date: Tue, 10 Feb 2015 14:06:43 -0800 [thread overview]
Message-ID: <xmqqoap1v2to.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CAP8UFD1pWH5yaJaJ_gV1t5q5qfgs58AtcSr+ZqDTnWzfHK1uBw@mail.gmail.com> (Christian Couder's message of "Sat, 7 Feb 2015 23:19:31 +0100")
Christian Couder <christian.couder@gmail.com> writes:
> On Sat, Feb 7, 2015 at 9:20 PM, Junio C Hamano <gitster@pobox.com> wrote:
>
>> Another problem I have with "filter out during the output phase"
>> comes from the semantics/correctness in the resulting code, and I
>> suspect that it would need to be done a lot earlier, before you
>> allow the logic such as "if I have X, do this, but if there is no X,
>> do this other thing". If you have an X that is empty in the input,
>> trimming that before such logic kicks in and trimming that in the
>> final output phase would give different results, and I think the
>> latter would give a less intuitive result.
>
> I think it is much better in the output phase because it is very
> natural for some projects to have a template message with empty
> trailers like this:
That is exactly my point. With empty trailers in the input, "Add
this iff there is no existing one" will be made useless.
I am *not* saying that we must not have a filter at the output
phrase. If anything, it would allow people to be more sloppy and
hide the problem under the rug. Your code may have a bug or design
problem that adds an empty one somewhere even when the user told you
that she does not want an empty one in the result. The user may be
sloppy and say "Add this key-value" unconditionally, instead of
having to do "What is the value I want to add? Oh, it is not empty,
so I'll ask the trailer machiner to add this key-value there".
I am saying that not filtering the input and whatever intermediate
result you produce [*1*] will make the end result much less useful.
[Footnote]
*1* Filtering intermediate result of course can be done by making
sure you do not add an empty one in the first place.
prev parent reply other threads:[~2015-02-10 22:06 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-07 13:11 [PATCH 1/3] trailer: add a trailer.trimEmpty config option Christian Couder
2015-02-07 20:20 ` Junio C Hamano
2015-02-07 22:19 ` Christian Couder
2015-02-09 18:23 ` Junio C Hamano
2015-02-10 21:58 ` Junio C Hamano
2015-02-10 22:06 ` Junio C Hamano [this message]
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=xmqqoap1v2to.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox.com \
--cc=chriscool@tuxfamily.org \
--cc=christian.couder@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).