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

Re: [PATCH v2 1/2] sh-setup: Write a new require_clean_work_tree function

From
Ramkumar Ramachandra <artagnon@gmail.com>
Date
Oct 1, 2010, 07:21 UTC
Message-ID
<20101001072149.GA24171@kytes>
In-Reply-To
<20101001053721.GB6184@burratino>
Hi Jonathan,
Jonathan Nieder writes:
Show 33 quoted lines
> Some noise about Cc and Reviewed-by tags:
> 
>  - I have been using Cc lines in patches to say "I consider this
>    person something of a maintainer of the subsystem in question
>    and would be particularly interested in his or her opinion."
>    The idea is that if the patch does not get acked and a Cc line
>    remains, people can tell that from the log.  The benefits:
> 
>     1) I remember to cc them
>     2) later it is easy to find who looks like a maintainer
>     3) the lack of ack is more obvious
> 
>    Checking Linux's Documentation/SubmittingPatches, I find that
>    that is a misuse on my part (sorry).  A person passing on a patch
>    to Linus is rather supposed to _add_ a Cc line in the rare event
>    that they want to explain that a certain person had an opportunity
>    to comment but did not comment (so Linus can know about their
>    indifference to the patch, I guess).
> 
>    Neither use is as important for git, where many people read the
>    list so it is not as important to cc people to get proper review.
> 
>  - I also used to abuse Cc lines to fit in contact information for a
>    person who helped me, until I learned to use Helped-by and similar
>    neologisms for that.  Sorry.
> 
>  - Again from Documentation/SubmittingPatches, I learned a while ago
>    that Reviewed-by, unlike Acked-by, can only be offered by the
>    reviewer and means that she is satisfied that the patch is ready
>    for application.
> 
> If you just want to credit Matthieu, I suppose it would make sense to
> say "Thanks to Matthieu Moy for such-and-such" somewhere.

Thanks for the lengthy explanation. Perhaps we can document this in Git's SubmittingPatches?

Are all these tags useful? Should I include more such as "Mentored-by" or explicity mention that the contributor is free to come up with other freeform tags as she deems appropriate?

Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com>
-- 8< --
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index ece3c77..84c9eaa 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -264,12 +264,25 @@ the change to its true author (see (2) above).
 Also notice that a real name is used in the Signed-off-by: line. Please
 don't hide your real name.
 
-Some people also put extra tags at the end.
-
-"Acked-by:" says that the patch was reviewed by the person who
-is more familiar with the issues and the area the patch attempts
-to modify.  "Tested-by:" says the patch was tested by the person
-and found to have the desired effect.
+Some extra tags you can use in the end along with their meanings are:
+
+1. "Reported-by:" is used to to credit someone who found the bug that
+   the patch attempts to fix.
+2. "Acked-by:" says that the patch was acknowledged by the person who
+   is more familiar with the issues and the area the patch attempts to
+   modify.
+3. "Reviewed-by:", unlike the other tags, can only be offered by the
+   reviewer and means that she is completely satisfied that the patch
+   is ready for application.  It is usually offered only after a
+   detailed review.
+4. "Tested-by:" is used to indicate that the person applied the patch
+   and found it to have the desired effect.
+5. "Thanks-to:" is a more broad term used to credit someone who helped
+   with the patch in some way. The person perhaps gave an idea or
+   reviewed some part of the patch without awarding a "Reviewed-by".
+6. "Based-on-patch-by:" is used to credit the person whose patch yours
+   is based on. The original patch was probably not considered for
+   inclusion due to several reasons.
 
 ------------------------------------------------
 An ideal patch flow
Previous: Jonathan NiederNext: Jonathan Nieder
Message 6 of 19 in “Eliminate cryptic "needs update" error message”
  1. 0/2 Eliminate cryptic "needs update" error messageRamkumar Ramachandra, Sep 30, 2010
  2. 1/2 sh-setup: Write a new require_clean_work_tree functionRamkumar Ramachandra, Sep 30, 2010
  3. Junio C HamanoSep 30, 2010
  4. Ramkumar RamachandraOct 1, 2010
  5. Jonathan NiederOct 1, 2010
  6. Ramkumar RamachandraOct 1, 2010
  7. Jonathan NiederOct 1, 2010
  8. Ramkumar RamachandraOct 1, 2010
  9. Jonathan NiederOct 1, 2010
  10. Sverre RabbelierOct 1, 2010
  11. 0/2 Eliminate cryptic "needs update" error messageRamkumar Ramachandra, Oct 2, 2010
  12. 1/2 sh-setup: Write a new require_clean_work_tree functionRamkumar Ramachandra, Oct 2, 2010
  13. Ramkumar RamachandraOct 2, 2010
  14. SubmittingPatches: Document some extra tags used in commit messagesRamkumar Ramachandra, Oct 2, 2010
  15. Junio C HamanoOct 1, 2010
  16. 2/2 Porcelain scripts: Rewrite cryptic "needs update" error messageRamkumar Ramachandra, Sep 30, 2010
  17. Junio C HamanoSep 30, 2010
  18. Ramkumar RamachandraOct 1, 2010
  19. Junio C HamanoOct 3, 2010

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.