From: Jonathan Nieder <firstname.lastname@example.org> To: Jeff Hostetler via GitGitGadget <email@example.com> Cc: firstname.lastname@example.org, email@example.com, Junio C Hamano <firstname.lastname@example.org>, Derrick Stolee <email@example.com> Subject: Re: [PATCH 0/8] WIP: trace2: a new trace facility Date: Mon, 14 Jan 2019 17:05:28 -0800 [thread overview] Message-ID: <20190115010528.GJ162110@google.com> (raw) In-Reply-To: <firstname.lastname@example.org> Hi, Jeff Hostetler wrote: > This patch series contains a new trace2 facility that hopefully addresses > the recent trace- and structured-logging-related discussions. The intent is > to eventually replace the existing trace_ routines (or to route them to the > new trace2_ routines) as time permits. I've been running with these patches since last October. A few thoughts: I like the API. The logs are a bit noisy and especially wide. For my use, the function name is not too important since we can get that from the file and line number. Should we have a way to omit some fields, or is that for post-processing? We don't find the JSON easy to parse and would prefer a binary format. When I apply the patches, Git complains about whitespace problems (trailing whitespace, etc). Aside from that kind of easily correctible issue (trailing whitespace), I'd be in favor of taking these patches pretty much as-is and making improvements in tree. Any objections to that, or do you have other thoughts on where this should go? If that sounds reasonable to you, I can send a clean version of these based against current "master". If I understand correctly, then https://github.com/jeffhostetler/git branch gvfs-trace2-v4 contains some improvements, so as a next step I'd try to extract those as incremental patches on top. What do you think? Thanks, Jonathan
next prev parent reply other threads:[~2019-01-15 1:05 UTC|newest] Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-08-31 16:49 Jeff Hostetler via GitGitGadget 2018-08-31 16:49 ` [PATCH 1/8] trace2: create new combined " Jeff Hostetler via GitGitGadget 2018-08-31 17:19 ` Derrick Stolee 2018-09-04 22:12 ` Stefan Beller 2018-09-04 22:30 ` Junio C Hamano 2018-09-05 15:51 ` Jeff Hostetler 2018-09-05 15:01 ` Jeff Hostetler 2018-08-31 16:49 ` [PATCH 2/8] trace2: add trace2 to main Jeff Hostetler via GitGitGadget 2018-08-31 16:49 ` [PATCH 3/8] trace2: demonstrate trace2 regions in wt-status Jeff Hostetler via GitGitGadget 2018-08-31 16:49 ` [PATCH 4/8] trace2: demonstrate trace2 child process classification Jeff Hostetler via GitGitGadget 2018-08-31 16:50 ` [PATCH 5/8] trace2: demonstrate instrumenting do_read_index Jeff Hostetler via GitGitGadget 2018-08-31 16:50 ` [PATCH 6/8] trace2: demonstrate instrumenting threaded preload_index Jeff Hostetler via GitGitGadget 2018-08-31 16:50 ` [PATCH 7/8] trace2: demonstrate setting sub-command parameter in checkout Jeff Hostetler via GitGitGadget 2018-08-31 16:50 ` [PATCH 8/8] trace2: demonstrate use of regions in read_directory_recursive Jeff Hostetler via GitGitGadget 2018-08-31 17:19 ` [PATCH 0/8] WIP: trace2: a new trace facility Derrick Stolee 2018-09-06 15:13 ` [RFC PATCH 0/6] Use trace2 in commit-reach Derrick Stolee 2018-09-06 15:13 ` [RFC PATCH 1/6] commit-reach: add trace2 telemetry and walk count Derrick Stolee 2018-09-06 15:13 ` [RFC PATCH 2/6] comit-reach: use trace2 for commit_contains_tag_algo Derrick Stolee 2018-09-06 15:13 ` [RFC PATCH 3/6] commit-reach: use trace2 in can_all_from_reach Derrick Stolee 2018-09-06 15:13 ` [RFC PATCH 4/6] test-tool: start trace2 environment Derrick Stolee 2018-09-06 15:13 ` [RFC PATCH 5/6] test-lib: add run_and_check_trace2 Derrick Stolee 2018-09-06 15:13 ` [RFC PATCH 6/6] commit-reach: fix first-parent heuristic Derrick Stolee 2018-10-11 1:50 ` Jonathan Nieder 2018-10-11 11:00 ` Derrick Stolee 2019-01-15 1:05 ` Jonathan Nieder [this message] 2019-01-15 17:03 ` [PATCH 0/8] WIP: trace2: a new trace facility Jeff Hostetler
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=20190115010528.GJ162110@google.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH 0/8] WIP: trace2: a new trace facility' \ /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
Code repositories for project(s) associated with this 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).