Re: [PATCH v11 06/10] bisect: don't mix option parsing and non-trivial code

[Junio C Hamano <gitster@pobox.com>]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Junio C Hamano <gitster@pobox.com> 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.