git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Robert Coup via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, Taylor Blau <me@ttaylorr.com>,
	Robert Coup <robert@coup.net.nz>
Subject: Re: [PATCH v2] upload-pack: add tracing for fetches
Date: Mon, 23 Oct 2023 14:55:55 -0400	[thread overview]
Message-ID: <20231023185555.GD1537181@coredump.intra.peff.net> (raw)
In-Reply-To: <pull.1598.v2.git.1697577168128.gitgitgadget@gmail.com>

On Tue, Oct 17, 2023 at 09:12:47PM +0000, Robert Coup via GitGitGadget wrote:

> Information on how users are accessing hosted repositories can be
> helpful to server operators. For example, being able to broadly
> differentiate between fetches and initial clones; the use of shallow
> repository features; or partial clone filters.
> 
> a29263c (fetch-pack: add tracing for negotiation rounds, 2022-08-02)
> added some information on have counts to fetch-pack itself to help
> diagnose negotiation; but from a git-upload-pack (server) perspective,
> there's no means of accessing such information without using
> GIT_TRACE_PACKET to examine the protocol packets.
> 
> Improve this by emitting a Trace2 JSON event from upload-pack with
> summary information on the contents of a fetch request.
> 
> * haves, wants, and want-ref counts can help determine (broadly) between
>   fetches and clones, and the use of single-branch, etc.
> * shallow clone depth, tip counts, and deepening options.
> * any partial clone filter type.
> 
> Signed-off-by: Robert Coup <robert@coup.net.nz>
> ---
>     upload-pack: add tracing for fetches
>     
>     
>     Changes since V1
>     ================
>     
>      * Don't generate the JSON event unless Trace2 is active.
>      * Code style fix.

Thanks, the first bullet point there addressed my only concern.

The rest looks good to me overall. I think it is a useful feature to
have (as Taylor mentioned, GitHub has something similar via custom
code), but it has been long enough since I have operated a server that I
don't have opinions on what specific items should or should not be
included. :)

-Peff


  parent reply	other threads:[~2023-10-23 18:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-11 16:04 [PATCH] upload-pack: add tracing for fetches Robert Coup via GitGitGadget
2023-10-11 21:26 ` Taylor Blau
2023-10-11 21:32 ` Taylor Blau
2023-10-11 22:33   ` Robert Coup
2023-10-11 22:27 ` Jeff King
2023-10-11 22:36   ` Robert Coup
2023-10-17 21:12 ` [PATCH v2] " Robert Coup via GitGitGadget
2023-10-23 18:28   ` Robert Coup
2023-10-23 18:55   ` Jeff King [this message]
2023-10-30 20:25     ` Taylor Blau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231023185555.GD1537181@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=me@ttaylorr.com \
    --cc=robert@coup.net.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).