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

Re: [PATCH] send-email: handle multiple Cc addresses when reading mbox message

From
Junio C Hamano <gitster@pobox.com>
Date
Feb 14, 2009, 08:16 UTC
Message-ID
<7v63jdxwl9.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<76718490902131642y62b81bfat129cfbeda7957ff8@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
Show 9 quoted lines
> It goes like this:
>
> Me: Notice wart
> Me: Cut wart off (i.e. submit patch)
> Reviewer: Sorry, you didn't cut that wart off to my standards, unless
> you can do it better, I'd rather have the wart.
>
> I dunno, maybe I'm too sensitive and don't have the fortitude for
> contributing to git.
Different people have different priorities and judging criteria.

To some authors, code is the only thing that matters and they say a crappy commit log message is Ok if the code works. I actually do not even read the patch if the commit log message does not clearly express what problem the author is trying to address, because I always have other patches to attend to, and if the author cannot formulate his thought clearly in the commit log message, it is likely that the code doesn't, either, and even if it does, the code speaks only about how it does what it does, and not much about _why_ it is so, which is the most important thing down the road.

Some people comment more on readability of the patch and format of the code while some others let them pass and concentrate on performance and correctness.

All of them are important, and reviewers, together with the original author, complement each other's weakness to work toward a better system.

The first thing to learn is to tell the difference between "you didn't cut that wart off to my standards, unless you can do it better, I'd rather have the wart." and "you claim you have cut the wart off, but that's minor compared to the wart you are missing here which can be cut at the same time without too much effort; let's do so at the same time before we all forget".

The review comments I read on this list are more often the latter, but I can certainly understand some authors, being so excited about and fond of his own creation, mistake it as the former. Two tricks I learned to avoid that trap while working on git, and especially when git was still young and I was a contributor, was to sleep on things, and to always consider the possibility that I _might_ be wrong. The latter takes some practice, and I admit I still haven't mastered it yet, but I am trying.

Previous: Jeff King
Message 20 of 20 in “send-email: handle multiple Cc addresses when reading mbox message”
  1. send-email: handle multiple Cc addresses when reading mbox messageJay Soffian, Feb 13, 2009
  2. Thomas RastFeb 13, 2009
  3. Jay SoffianFeb 13, 2009
  4. Jay SoffianFeb 13, 2009
  5. Jay SoffianFeb 14, 2009
  6. 1/3 send-email: correct logic error with --suppress-cc=ccJay Soffian, Feb 14, 2009
  7. 2/3 send-email: don't call unquote_rfc2047 unnecessarilyJay Soffian, Feb 14, 2009
  8. 3/3 send-email: --suppress-cc improvementsJay Soffian, Feb 14, 2009
  9. 3/3 send-email: --suppress-cc improvementsJay Soffian, Feb 14, 2009
  10. Junio C HamanoFeb 14, 2009
  11. Jay SoffianFeb 14, 2009
  12. 1/3 send-email: correct logic error with --suppress-cc=ccJay Soffian, Feb 14, 2009
  13. Junio C HamanoFeb 14, 2009
  14. Jay SoffianFeb 14, 2009
  15. Junio C HamanoFeb 14, 2009
  16. Thomas RastFeb 14, 2009
  17. Jeff KingFeb 14, 2009
  18. Jay SoffianFeb 14, 2009
  19. Jeff KingFeb 14, 2009
  20. Junio C HamanoFeb 14, 2009

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.