Re: [BUG] git-am silently applying patches incorrectly

[Alexander Miseler <alexander@miseler.de>]

On 04.03.2011 22:33, Junio C Hamano wrote:
> (Please don't cull Cc line).

Sorry. I used the nice gmane web interface and hoped that it keeps the CC intact, which it apparently doesn't. I guess i 
will go old school now and use the mailing list via actual emails :)


> Try implementing that warning logic, and using it in real-life projects.
> You don't actually have to _code_ it, but merely imagining how it would
> work and perform would be sufficient for you to realize that it would be
> quite expensive (you need to find all the possible mismatches, essentially
> scanning the whole file), and worse yet, it would be annoyingly noisy with
> many false positives, because in many real-life projects, end of function
> tends to match the problematic pattern that triggered this discussion
> quite often even without patches that introduce more of the pattern.
>
> Unless you can reduce the false hits to manageable levels, such a warning
> is not very useful (it would be useful as a lame excuse "we warned, but
> you took the suspicious result", but that does not help the users).
>
> In short, Linus and I both know what you are talking about, and we may
> revisit that issue later, but the thing is that it would not be very
> pleasant, and not something that can be done in one sitting during a
> single discussion thread on the list.

Understood. On a side note: if this problem is tackled it might be sensible to add a heuristic to git format-patch that 
increases the context size for hunks that are likely to be ambiguous. "Likely to be ambiguous" is of course a problem in 
itself but even a less than perfect detection might be helpful and it would suffer less from some of the aforementioned 
problems, like noisiness/false hits, which would just increase the patch size instead of harassing the user.