Re: [PATCHv3] git apply: option to ignore whitespace differences

From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Date: Jul 29, 2009, 08:20 UTC
Message-ID: <cb7bb73a0907290120x72d0ae99p7cfdd2b88264a24a@mail.gmail.com>
In-Reply-To: <7vab2oynhm.fsf@alter.siamese.dyndns.org>

On Wed, Jul 29, 2009 at 9:09 AM, Junio C Hamano<gitster@pobox.com> wrote:

Show 18 quoted lines

> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
>
>> Actually, one thing that I've been thinking about doing is to adjust
>> the new lines to match the kind of whitespace change the context line
>> underwent. Example: if all the context lines had the change 4 spaces
>> -> tab, it would be nice to have the new lines undergo the same
>> change. However, this is going to be rather hard to implement.
>
> Doing so will be actively wrong.
>
> In the case of "whitespace=fix", it is justifiable to update ws broken
> context lines while applying a ws corrected patch to a ws broken target,
> and it also is justifiable not to update context lines while applying a ws
> broken patch to a ws corrected target, because it is clear which one has
> the correct whitespace layout (i.e. output of ws_fix_copy() by definition
> is the correct outcome).  But in your example, it is not clear if the
> layout using 4 spaces is correct or the one with a tab.  The tool should
> refrain from guessing in such a case.

I was thinking more about consistency than 'correctness' in this case, actually. Typical scenario would be: patch is created for a file using a given whitespace convention (e.g. 4 spaces). File is updated to match the rest of the project (tabs). Patch would now introduce the wrong whitespace convention for the new lines.

Of course, whitespace can (and should) be fixed a posteriori, but when doing a rebase this can get quite annoying. So some kind of automatic way to do it would be nice. But I don't think I'd get around to such a feature any time soon. (Also, the merge case has a higher priority.)

-- 
Giuseppe "Oblomov" Bilotta