Christian Couder <christian.cou...@gmail.com> writes: > On Sat, Feb 7, 2015 at 9:20 PM, Junio C Hamano <gits...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
