Hi Junio! On Mo, 25 Mai 2015, Junio C Hamano wrote: > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > > > I like this idea. > > I don't. > > > My use case is determining whether a patch to a pristine-tar > > repository introduced trailing whitespace (which is not okay) or > > just left it there (which is okay). > > In your use case, where keeping trailing blank that is otherwise not > OK is fine only when the breakage was inherited from the preimage, > wouldn't it be equally fine to keep other kinds of breakages as long > as they were inherited from the preimage? E.g. "The original used > 8-space as leading indent, and you would not use that for your new > lines, but the breakage was inherited from the preimage" would want > to be treated the same way, no? Why trailing blanks so special? It was the one I am interesting in and also the one that I usually try to avoid ;) (In fact, I thought if the other options would be needed, one could add additional suboptions for core.whitespace as well, so one would be able to exactly say, what kind of things one would like to see and which could be different for new lines and old lines). > > So, from that point of view, your "use case" does not justify this > particular implementation that special-cases trailing blanks on > deleted lines and mark them [*1*]. > > If the implementation were addition of a new option to check and > mark all kinds of errors core.whitespace would catch for new lines > also for old lines, then it would be a somewhat different story. I > personally do not find such an option interesting, but at least I > can understand why some people might find it useful. Wouldn't that mean, that one couldn't see different kind of whitespace markings for newlines and deleted lines? I don't know, if one would want that a configuration however. However, as I don't know the codebase very well, I doubt I can implement this. > [Footnote] > > *1* To support your use case with the ultimate ease-of-use, it would > be best if the new option were to squelch the whitespace error on > the new line when it was inherited from the old line, which is > different from showing and marking the breakage on the old line. > But I do not think it can be implemented sanely, so I will not go > there. Aside from the difficulties it would take to do this, personally, I don't like this option. Because I like to see such problems, but just want to know whether a particular patch has introduced the problem or not. Best, Christian -- In den Fragen im gemeinen Leben, wie man etwas am besten tun könnte, wird ein gewisses Maximum gesucht. -- Georg Christoph Lichtenberg -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html