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

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

From
AMAlexander Miseler <alexander@miseler.de>
Date
Mar 4, 2011, 23:09 UTC
Message-ID
<4D717116.3050305@miseler.de>
In-Reply-To
<7vtyfi606a.fsf@alter.siamese.dyndns.org>
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 :)

Show 17 quoted lines
> 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.

Previous: Colin GuthrieNext: Junio C Hamano
Message 21 of 34 in “[BUG] git-am silently applying patches incorrectly”
  1. Colin GuthrieMar 4, 2011
  2. Drew NorthupMar 4, 2011
  3. Colin GuthrieMar 4, 2011
  4. Junio C HamanoMar 4, 2011
  5. Junio C HamanoMar 4, 2011
  6. Junio C HamanoMar 4, 2011
  7. Junio C HamanoMar 4, 2011
  8. Linus TorvaldsMar 4, 2011
  9. Junio C HamanoMar 4, 2011
  10. Alexander MiselerMar 4, 2011
  11. Junio C HamanoMar 4, 2011
  12. Colin GuthrieMar 4, 2011
  13. Junio C HamanoMar 4, 2011
  14. Junio C HamanoMar 4, 2011
  15. Colin GuthrieMar 5, 2011
  16. Junio C HamanoMar 6, 2011
  17. Junio C HamanoMar 6, 2011
  18. Jonathan NiederMar 6, 2011
  19. Junio C HamanoMar 6, 2011
  20. Colin GuthrieMar 7, 2011
  21. Alexander MiselerMar 4, 2011
  22. Junio C HamanoMar 5, 2011
  23. Junio C HamanoMar 4, 2011
  24. Drew NorthupMar 4, 2011
  25. 0/2 i18n: add ngettext stubJonathan Nieder, Mar 9, 2011
  26. 1/2 i18n: add stub ngettext implementationJonathan Nieder, Mar 9, 2011
  27. 2/2 i18n: avoid conflict with ngettext from libintlJonathan Nieder, Mar 9, 2011
  28. Junio C HamanoMar 9, 2011
  29. Jonathan NiederMar 9, 2011
  30. Junio C HamanoMar 9, 2011
  31. i18n: add stub Q_() wrapper for ngettextJonathan Nieder, Mar 10, 2011
  32. Junio C HamanoMar 10, 2011
  33. Ævar Arnfjörð BjarmasonMar 10, 2011
  34. Ævar Arnfjörð BjarmasonMar 10, 2011

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.