Christian Brabandt <cbli...@256bit.org> writes:
>> But as I said in the other message, I think that the approach this
>> patch takes goes in a wrong direction. Instead of adding a single
>> "check and highlight this and only kind of breakage on preimage"
>> option as a new kind to existing "what kind of use of whitespaces
>> are errors" set, it would be more sensible to add a single "check
>> and highlight breakages on preimage lines as well" option that is
>> orthogonal to the existing ones that specify "what kind of use of
>> whitespaces are errors".
>
> Oh well, too bad. It sounded like a good idea...
Oh, don't get me wrong. I do not think it is not a good idea
(i.e. problem and general strategy to solve it).
Problem:
Sometimes it is desirable to keep existing whitespace breakages
while working on fixes and other changes of substance. The user
however gets whitespace errors painted only on new lines in the
output from "git diff", and this makes it hard to tell if they
were introduced by the user's change or came from the original.
Strategy:
By painting whitespace breakages in the old lines, the user can
eyeball and find the corresponding old lines when whitespace
errors on new lines are painted. If the corresponding old lines
have the same errors, the user can see they were inherited from
the original.
These may be a pair of reasonable problem to solve and a general
strategy to solve it.
What I said was *not* good was the particular execution, the
approach that the patch took.
--
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
