git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
Junio C Hamano <gitster@pobox.com>
Date
Jun 30, 2015, 15:56 UTC
Message-ID
<xmqqk2ul8a1h.fsf@gitster.dls.corp.google.com>
In-Reply-To
<vpq7fqla06v.fsf@anie.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
Show 9 quoted lines
> 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.
Previous: Matthieu MoyNext: Matthieu Moy
Message 10 of 15 in “bisect terms”
  1. 00/10 bisect termsMatthieu Moy, Jun 29, 2015
  2. 01/10 bisect: correction of typoMatthieu Moy, Jun 29, 2015
  3. 02/10 Documentation/bisect: move getting help section to the endMatthieu Moy, Jun 29, 2015
  4. 03/10 Documentation/bisect: revise overall contentMatthieu Moy, Jun 29, 2015
  5. 04/10 bisect: replace hardcoded "bad|good" by variablesMatthieu Moy, Jun 29, 2015
  6. 05/10 bisect: simplify the addition of new bisect termsMatthieu Moy, Jun 29, 2015
  7. 06/10 bisect: don't mix option parsing and non-trivial codeMatthieu Moy, Jun 29, 2015
  8. Junio C HamanoJun 29, 2015
  9. Matthieu MoyJun 30, 2015
  10. Junio C HamanoJun 30, 2015
  11. 07/10 bisect: sanity check on termsMatthieu Moy, Jun 29, 2015
  12. 08/10 bisect: add the terms old/newMatthieu Moy, Jun 29, 2015
  13. 09/10 bisect: add 'git bisect terms' to view the current termsMatthieu Moy, Jun 29, 2015
  14. 10/10 bisect: allow setting any user-specified in 'git bisect start'Matthieu Moy, Jun 29, 2015
  15. Junio C HamanoJun 29, 2015

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.