Matthieu Moy <Matthieu.Moy@xxxxxxxxxxxxxxx> writes: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Matthieu, are you allowing your editor to corrupt the number of >> lines in the hunk on the @@ ... @@ hunk header? "diff" mode in >> Emacs does that, > > Indeed. There's magic in Emac's diff-mode to keep the header up to date, > but it seems totally buggy. I manually deleted a tab (no line added, no > line removed) and it changed the number of lines in the header. I'd hesitate to call it "totally buggy", but (without reading its code, merely an observation of its behaviour from the outside) it seems that this behaviour comes from the fact that its theory of operation is fundamentally flawed. If it trusted the the original @@ ... @@ hunk header line and then adjusted the numbers as the user adds, deletes or modifies lines, we wouldn't be seeing this problem. Instead, it seems to totally ignore the original number of lines recorded on the hunk header, and counts what it deems to be part of the patch. The thing is, when people edit a patch, they do not start from scratch. They somehow prepare a patch with a tool, and its output is far more likely than not to record the correct number of lines on the hunk header. Not reading and trusting these numbers to see where the original patch before it lets the user edit it, and incorrectly including text outside the original patch in its own count, is simply being silly. Often, the last hunk of format-patch output has the "-- " signature marker, which looks to Emacs as if the patch wants to delete a line that has a dash and a space on it at the end. > I see that you still managed to apply the series in pu, thanks and sorry > for the inconvenience. It's just the matter of realizing how it was corrupt and then recounting the number of lines---a minor annoyance, not a big deal. Thanks. -- 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