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

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

From
Junio C Hamano <gitster@pobox.com>
Date
Mar 4, 2011, 21:33 UTC
Message-ID
<7vtyfi606a.fsf@alter.siamese.dyndns.org>
In-Reply-To
<loom.20110304T210337-216@post.gmane.org>
Alexander Miseler <alexander@miseler.de> writes:
Show 5 quoted lines
> 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.

Previous: Alexander MiselerNext: Colin Guthrie
Message 11 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.