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

Re: [PATCH v3 0/1] fetch: add trace2 instrumentation

From
Junio C Hamano <gitster@pobox.com>
Date
Nov 7, 2019, 05:21 UTC
Message-ID
<xmqqd0e4s1m2.fsf@gitster-ct.c.googlers.com>
In-Reply-To
<pull.451.v3.git.1573069152.gitgitgadget@gmail.com>
"erik chen via GitGitGadget" <gitgitgadget@gmail.com> writes:
Show 9 quoted lines
> Add trace2 regions to fetch-pack.c to better track time spent in the various
> phases of a fetch:
>
> * matching common remote and local refs
> * marking local refs as complete (part of the matching process)
>
> Both of these stages can be slow for repositories with many refs.
>
> Signed-off-by: Erik Chen erikchen@chromium.org [erikchen@chromium.org]

If the above is verbatim copy of what you wrote in 1/1, that is very much unappreciated X-<. A cover letter for a topic serves primarily just one purpose:

   It is a good place to present a birds-eye-view of a multi-patch
   topic; a high level description of the problem (e.g. how the
   issue manifests to the end users), an explanation of division of
   the problem into subproblems you made (if applicable), and
   interesting highlights of the solution would all be good things
   to have in there.
And as a topic goes through iterations, it gives you a good place to
summarize what changed since the previously reviewed iterations.  It
could be just a single liner "addressed all the review comments for
the previous iteration".  A well-written multi-patch topic also uses
the same after-three-dash technique used for a single-patch topic
(see below) to summarize what changed since the corresponding patch
in the series in the previous iteration (or just says "no changes
since the previous round"---that helps the reviewers a lot).
   
For a single-patch topic, there is no place for "here is an overall
birds-eyes-view picture because the changes described in the
proposed log message of individual patches are so big and complex".
A single-patch topic has one patch, that solves one problem and only
that problem well, so it should not need such a summary.  

When you want to summarize the changes since the previous iteration, you would write it between the three-dash-line (which appears after your sign-off) and the diffstat.

Thanks.
Previous: Erik ChenNext: Erik Chen
Message 16 of 22 in “fetch: add trace2 instrumentation”
  1. 0/1 fetch: add trace2 instrumentationerik chen via GitGitGadget, Nov 5, 2019
  2. 1/1 fetch: add trace2 instrumentationErik Chen via GitGitGadget, Nov 5, 2019
  3. Johannes SchindelinNov 6, 2019
  4. 0/2 fetch: add trace2 instrumentationerik chen via GitGitGadget, Nov 6, 2019
  5. 1/2 fetch: add trace2 instrumentationErik Chen via GitGitGadget, Nov 6, 2019
  6. 2/2 add whitespaceErik Chen via GitGitGadget, Nov 6, 2019
  7. 0/1 fetch: add trace2 instrumentationerik chen via GitGitGadget, Nov 6, 2019
  8. 1/1 fetch: add trace2 instrumentationErik Chen via GitGitGadget, Nov 6, 2019
  9. Junio C HamanoNov 7, 2019
  10. Derrick StoleeNov 18, 2019
  11. Junio C HamanoNov 19, 2019
  12. Erik ChenNov 19, 2019
  13. Erik ChenNov 19, 2019
  14. Erik ChenNov 19, 2019
  15. Erik ChenNov 19, 2019
  16. Junio C HamanoNov 7, 2019
  17. Erik ChenNov 19, 2019
  18. 0/1 fetch: add trace2 instrumentationerik chen via GitGitGadget, Nov 18, 2019
  19. 1/1 fetch: add trace2 instrumentationErik Chen via GitGitGadget, Nov 18, 2019
  20. 0/1 fetch: add trace2 instrumentationerik chen via GitGitGadget, Nov 19, 2019
  21. 1/1 fetch: add trace2 instrumentationErik Chen via GitGitGadget, Nov 19, 2019
  22. Junio C HamanoNov 20, 2019

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.