Jeff King <p...@peff.net> writes: > and so on. I haven't quite figured out what is going on. It looks like > we call update_pre_post_images with postlen==0, which causes it to just > write the fixed postimage into the existing buffer. But of course the > fixed version is bigger, because we are expanding the tabs into 8 > spaces (but it _doesn't_ break if each line starts with only one tab, > which confuses me).
I used to be intimately familiar with the update_pre_post_images() function, but the version after 86c91f91794c (git apply: option to ignore whitespace differences, 2009-08-04), I won't vouch for it doing anything sensible. We recently had to do 5de7166d46d2 (apply.c:update_pre_post_images(): the preimage can be truncated, 2012-10-12) to fix one of its corner cases but I would not be surprised if there are other cases the function gets it all wrong. I'd come back to the topic after I finish other tasks on my plate, so if somebody is inclined please go ahead digging this a bit further; I won't have much head start to begin with in this code X-<. -- 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
