Alexander Miseler <alexander@xxxxxxxxxx> writes: > It's a bit intimidating for a newbie to chime in on a discussion between the > creator and the maintainer, but: > IMHO the biggest problem here isn't the incorrectly, but rather the silently. > Reducing the chance of guessing incorrectly is good, but git-am still has to > guess sometimes and it should warn/inform the user when it does that. (Please don't cull Cc line). No need to feel intimidated. The patch under discussion was merely "first things first--let's fix the obviously wrong case that can be fixed without regression". 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html