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

Re: [PATCH] Makefile: make NO_ICONV really mean "no iconv"

From
Eric Sunshine <sunshine@sunshineco.com>
Date
Jun 17, 2018, 18:00 UTC
Message-ID
<CAPig+cTMEfu=x2dhUww3x2uk9-ANAK6eepC3hOsx4FE+1jTgBA@mail.gmail.com>
In-Reply-To
<a079d636-e70d-f383-ae87-ab890a636441@gmail.com>

On Sun, Jun 17, 2018 at 1:32 PM Kaartic Sivaraam <kaartic.sivaraam@gmail.com> wrote:

Show 18 quoted lines
> On Friday 15 June 2018 01:13 PM, Eric Sunshine wrote:
> > On Fri, Jun 15, 2018 at 2:58 AM Simon Ruderich <simon@ruderich.org> wrote:
> >> Should we put the part about MacOS's make into the commit
> >> message? Seems like relevant information for future readers.
> >
> > No. The bit of commentary mentioning MacOS's very old 'make' was just
> > talking about a possible alternate way of implementing the change.
> > That alternative was not chosen, so talking about old 'make' in the
> > commit message would be confusing for readers.
>
> Interesting. Documentation/SubmittinPatches reads:
>
>     The body should provide a meaningful commit message, which:
>     <snip>
>     . alternate solutions considered but discarded, if any.
>
> The consensus has changed, maybe? In which case, should we remove that
> statement from there?

Whether or not to talk about alternate solutions in the commit message is a judgment call. Same for deciding what belongs in the commit message proper and what belongs in the "commentary" section of a patch. A patch author should strive to convey the problem succinctly in the commit message, to not overload the reader with unnecessary (or confusing) information, while, at the same time, not be sparing with information which is genuinely needed to understand the problem and solution.

Often, this can be done without talking about alternatives; often even without spelling out the solution in detail or at all since the solution may be "obvious", given a well-written problem description. Complex cases, or cases in which multiple solutions may be or seem valid, on the other hand, might warrant talking about those alternate solutions, so we probably don't want to drop that bullet point. Perhaps, instead, it can be re-worded a bit to make it sound something other than mandatory (but I can't think of a good way to phrase it; maybe you can?).

Previous: Kaartic SivaraamNext: Kaartic Sivaraam
Message 9 of 15 in “Is NO_ICONV misnamed or is it broken?”
  1. Mahmoud Al-QudsiJun 14, 2018
  2. Makefile: make NO_ICONV really mean "no iconv"Eric Sunshine, Jun 15, 2018
  3. Jeff KingJun 15, 2018
  4. Eric SunshineJun 15, 2018
  5. Jeff KingJun 15, 2018
  6. Simon RuderichJun 15, 2018
  7. Eric SunshineJun 15, 2018
  8. Kaartic SivaraamJun 17, 2018
  9. Eric SunshineJun 17, 2018
  10. Doc/SubmittingPatches: re-phrashing a sentence about alternate solutions (was Re: [PATCH] Makefile: make NO_ICONV really mean "no iconv")Kaartic Sivaraam, Jun 17, 2018
  11. Jeff KingJun 18, 2018
  12. Junio C HamanoJun 18, 2018
  13. Mahmoud Al-QudsiJun 15, 2018
  14. Christian CouderJun 17, 2018
  15. Eric SunshineJun 17, 2018

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.