Re: [PATCH] xdiff: trim common tail with -U0 after diff

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stefan Beller <sbeller@xxxxxxxxxx> writes:

> So I tried finding out more about this hack,
> and found the patch that introduced the common tail trimming at
>   https://public-inbox.org/git/7vmysez0oa.fsf@xxxxxxxxxxxxxxxxxxxxxxxxxx/
>   913b45f51b (xdi_diff: trim common trailing lines, 2007-12-13)

A relevant one that makes me hesitate to take this kind of change is
this:

https://public-inbox.org/git/alpine.LFD.0.9999.0712202009290.21557@xxxxxxxxxxxxxxxxxxxxxxxxxx/#t

that resulted in this change:

commit d2f82950a9226ae1102a7a97f03440a4bf8c6c09
Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Date:   Thu Dec 20 20:22:46 2007 -0800

    Re(-re)*fix trim_common_tail()
    
    The tar-ball and the git archive itself is fine, but yes, the diff from
    2.6.23 to 2.6.24-rc6 is bad. It's the "trim_common_tail()" optimization
    that has caused way too much pain.
    
    Very interesting breakage. The patch was actually "correct" in a (rather
    limited) technical sense, but the context at the end was missing because
    while the trim_common_tail() code made sure to keep enough common context
    to allow a valid diff to be generated, the diff machinery itself could
    decide that it could generate the diff differently than the "obvious"
    solution.
    
    Thee sad fact is that the git optimization (which is very important for
    "git blame", which needs no context), is only really valid for that one
    case where we really don't need any context.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux