git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: "tenglong.tl" <dyroneteng@gmail.com>
Cc: derrickstolee@github.com, git@jeffhostetler.com,
	git@vger.kernel.org, gitster@pobox.com, me@ttaylorr.com,
	tenglong.tl@alibaba-inc.com
Subject: Re: [PATCH v7 0/7] trace2: dump scope when print "interesting" config
Date: Tue, 19 Jul 2022 13:42:37 +0200	[thread overview]
Message-ID: <220719.86tu7duxl3.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <20220719112612.46679-1-tenglong.tl@tenglongtldeMacBook-Pro.local>


On Tue, Jul 19 2022, tenglong.tl wrote:

>> Yeah likewise, it even applies directly on master. But I can live with
>> it :)
>
> Sorry, may I ask what's the recommanded way to deal this, alway use
> tag or master on update?

We generally submit patches on a single "topic", what a "topic" is is
often fuzzy, and sometimes a topic that's mostly trying to do X will fix
or change some unrelated Y "while at it".

But patch or patches at the end of a series don't depend on anything
that comes before them, and could be "cherry-pick"'d directly on top of
"master" that's generally a sign that you should be submitting two sets
of patches, not one.

Per
https://lore.kernel.org/git/2016ef2e342c2ec6517afa8ec3e57035021fb965.1650547400.git.dyroneteng@gmail.com/
the "let's log config" is just something you happened to run into on
this topic, but it might have just as well been some other command.

So I think it's better to split it up into its own topic.

>> One minor nit is that something like this (which needs to be fleshened
>> up) should be fixed up into 7/7 (and maybe we want to keep the "..."?):
>>
>> diff --git a/Documentation/technical/api-trace2.txt b/Documentation/technical/api-trace2.txt
>> index 49bb1ca1924..ce544982a37 100644
>> --- a/Documentation/technical/api-trace2.txt
>> +++ b/Documentation/technical/api-trace2.txt
>> @@ -716,7 +716,7 @@ The "exec_id" field is a command-unique id and is only useful if the
>>  ------------
>>  {
>>  	"event":"def_param",
>> -	...
>> +	"scope": ...
>>  	"param":"core.abbrev",
>>  	"value":"7"
>>  }
>
> I do a little check, the json format in this scenario is like :
>
> {
>   "event": "def_param",
>   "sid": "20220719T075535.279369Z-H1b0a19dc-P000093db",
>   "thread": "main",
>   "time": "2022-07-19T07:55:35.280720Z",
>   "file": "git.c",
>   "line": 461,
>   "scope": "global",
>   "param": "color.ui",
>   "value": "always"
> }
>
> So, I think this is ok maybe:
>
> diff --git a/Documentation/technical/api-trace2.txt b/Documentation/technical/api-trace2.txt
> index bb13ca3db8..d66da52686 100644
> --- a/Documentation/technical/api-trace2.txt
> +++ b/Documentation/technical/api-trace2.txt
> @@ -717,6 +717,7 @@ The "exec_id" field is a command-unique id and is only useful if the
>  {
>         "event":"def_param",
>         ...
> +       "scope":...
>         "param":"core.abbrev",
>         "value":"7"

Yes, that sound good, although I'd make that "scope" line be:

	"scope": "global" | "worktree" | <add more things to the list here>

Or just say:

	"scope": <a string that 'git config --show-scope' would return>,

Which covers all the possibilities, without hardcoding them there.

>  }
>
>> And that the addition to api-trace2.txt seems to partially be something
>> that should just link to Documentation/config/trace2.txt, i.e. it's
>> generally documenting an existing facility.
>
> Do you mean the modification about `trace2.configParams` and you suggest
> to make a link to Documentation/config/trace2.txt(actually as git-config[1])
> in /Documentation/technical/api-trace2.txt?

I mean that part of what you're adding is about this new "scope"
feature, but another part just seems to be explaining how the
trace2.configParams works in general.

For the "works in general" let's either link to git-config(1), or if
that explanation is lacking improve it & link to it.

>> I think it would be great in any case to have that 7/7 split into what
>> we do now & docs for that, and then the minor addition of "scope".
>
> Let me try to understand this, it's better to split [7/7] into two commits.
>
> First commit is to add docs in /Documentation/technical/api-trace2.txt to let
> reader to find the print-config ability, by the way link the doc about the
> GIT_TRACE2_CONFIG_PARAM and trace2.configparami in git-config[1].
>
> Like:
>
> commit 2db47572d4462e3788a92fd355b97df13b9bcc39
> Author: Teng Long <dyroneteng@gmail.com>
> Date:   Tue Jul 19 17:30:35 2022 +0800
>
>     api-trace2.txt: add docs to print config
>
>     It's supported to print "interesting" config value to tr2 log by
>     setting the "GIT_TRACE2_CONFIG_PARAMS" environment variable and
>     the "trace2.configparam" config, let's add the related docs.
>
>     Signed-off-by: Teng Long <dyroneteng@gmail.com>
>
> diff --git a/Documentation/technical/api-trace2.txt b/Documentation/technical/api-trace2.txt
> index bb13ca3db8..4e411f3306 100644
> --- a/Documentation/technical/api-trace2.txt
> +++ b/Documentation/technical/api-trace2.txt
> @@ -1207,6 +1207,45 @@ at offset 508.
>  This example also shows that thread names are assigned in a racy manner
>  as each thread starts and allocates TLS storage.
>
> +Print Configs::
> +
> +         Dump "interesting" config values to trace2 log.
> ++
> +The environment variable `GIT_TRACE2_CONFIG_PARAMS` and configuration
> +`trace2.configparams` can be used to output config values which you care
> +about(see linkgit:git-config[1). For example, assume that we want to
> +config different `color.ui` values in multiple scopes, such as:
> ++
> +----------------
> +$ git config --system color.ui never
> +$ git config --global color.ui always
> +$ git config --local color.ui auto
> +$ git config --list --show-scope | grep 'color.ui'
> +system  color.ui=never
> +global  color.ui=always
> +local   color.ui=auto
> +----------------
> ++
> +Then, mark the config `color.ui` as "interesting" config with
> +`GIT_TRACE2_CONFIG_PARAMS`:
> ++
> +----------------
> +$ export GIT_TRACE2_PERF_BRIEF=1
> +$ export GIT_TRACE2_PERF=~/log.perf
> +$ export GIT_TRACE2_CONFIG_PARAMS=color.ui
> +$ git version
> +...
> +$ cat ~/log.perf
> +d0 | main                     | version      |     |           |           |              | ...
> +d0 | main                     | start        |     |  0.000260 |           |              | /opt/git/master/bin/git version
> +d0 | main                     | cmd_ancestry |     |           |           |              | ancestry:[bash sshd sshd sshd systemd]
> +d0 | main                     | cmd_name     |     |           |           |              | version (version)
> +d0 | main                     | def_param    |     |           |           |              | color.ui:never
> +d0 | main                     | def_param    |     |           |           |              | color.ui:always
> +d0 | main                     | def_param    |     |           |           |              | color.ui:auto
> +d0 | main                     | exit         |     |  0.000470 |           |              | code:0
> +d0 | main                     | atexit       |     |  0.000477 |           |              | code:0
> +----------------
>  == Future Work

Yes, something like that, although it's a bit odd to discuss "scope"
here and not have the trace show it yet, but that's fixed below.:

> Second is actually what we do in [7/7], modify to support print scope names
> and update the docs which based on what we just add in the first commit
>
> Like:
>
>
> commit 615ab4864fce6b8042778aa78799ac2656785710 (HEAD -> tl/bitmap-append-trace2-outputs)
> Author: Teng Long <dyroneteng@gmail.com>
> Date:   Thu Jul 7 21:48:32 2022 +0800
>
>     tr2: dump names if config exist in multiple scopes
>
>     When we specify GIT_TRACE2_CONFIG_PARAMS or trace2.configparams,
>     trace2 will prints "interesting" config values to log. Sometimes,
>     when a config set in multiple scope files, the following output
>     looks like (the irrelevant fields are omitted here as "..."):
>
>     ...| def_param    |  ...  | core.multipackindex:false
>     ...| def_param    |  ...  | core.multipackindex:false
>     ...| def_param    |  ...  | core.multipackindex:false
>
>     As the log shows, even each config in different scope is dumped, but
>     we don't know which scope it comes from. Therefore, it's better to
>     add the scope names as well to make them be more recognizable. For
>     example, when execute:
>
>         $ GIT_TRACE2_PERF=1 \
>         > GIT_TRACE2_CONFIG_PARAMS=core.multipackIndex \
>         > git rev-list --test-bitmap HEAD"
>
>     The following is the ouput (the irrelevant fields are omitted here
>     as "..."):
>
>     Format normal:
>     ... git.c:461 ... def_param scope:system core.multipackindex=false
>     ... git.c:461 ... def_param scope:global core.multipackindex=false
>     ... git.c:461 ... def_param scope:local core.multipackindex=false
>
>     Format perf:
>
>     ... | def_param    | ... | scope:system | core.multipackindex:false
>     ... | def_param    | ... | scope:global | core.multipackindex:false
>     ... | def_param    | ... | scope:local  | core.multipackindex:false
>
>     Format event:
>
>     {"event":"def_param", ... ,"scope":"system","param":"core.multipackindex","value":"false"}
>     {"event":"def_param", ... ,"scope":"global","param":"core.multipackindex","value":"false"}
>     {"event":"def_param", ... ,"scope":"local","param":"core.multipackindex","value":"false"}
>
>     Signed-off-by: Teng Long <dyroneteng@gmail.com>
>
> diff --git a/Documentation/technical/api-trace2.txt b/Documentation/technical/api-trace2.txt
> index 4e411f3306..50f1e0c259 100644
> --- a/Documentation/technical/api-trace2.txt
> +++ b/Documentation/technical/api-trace2.txt
> @@ -717,6 +717,7 @@ The "exec_id" field is a command-unique id and is only useful if the
>  {
>         "event":"def_param",
>         ...
> +       "scope":...
>         "param":"core.abbrev",
>         "value":"7"
>  }
> @@ -1240,9 +1241,9 @@ d0 | main                     | version      |     |           |           |
>  d0 | main                     | start        |     |  0.000260 |           |              | /opt/git/master/bin/git version
>  d0 | main                     | cmd_ancestry |     |           |           |              | ancestry:[bash sshd sshd sshd systemd]
>  d0 | main                     | cmd_name     |     |           |           |              | version (version)
> -d0 | main                     | def_param    |     |           |           |              | color.ui:never
> -d0 | main                     | def_param    |     |           |           |              | color.ui:always
> -d0 | main                     | def_param    |     |           |           |              | color.ui:auto
> +d0 | main                     | def_param    |     |           |           | scope:system | color.ui:never
> +d0 | main                     | def_param    |     |           |           | scope:global | color.ui:always
> +d0 | main                     | def_param    |     |           |           | scope:local  | color.ui:auto
>  d0 | main                     | exit         |     |  0.000470 |           |              | code:0
>  d0 | main                     | atexit       |     |  0.000477 |           |              | code:0
>  ----------------
> diff --git a/trace2/tr2_tgt_event.c b/trace2/tr2_tgt_event.c
> index c5c8cfbbaa..37a3163be1 100644
> --- a/trace2/tr2_tgt_event.c
> +++ b/trace2/tr2_tgt_event.c
> @@ -479,9 +479,12 @@ static void fn_param_fl(const char *file, int line, const char *param,
>  {
>         const char *event_name = "def_param";
>         struct json_writer jw = JSON_WRITER_INIT;
> +       enum config_scope scope = current_config_scope();
> +       const char *scope_name = config_scope_name(scope);
>
>         jw_object_begin(&jw, 0);
>         event_fmt_prepare(event_name, file, line, NULL, &jw);
> +       jw_object_string(&jw, "scope", scope_name);
>         jw_object_string(&jw, "param", param);
>         jw_object_string(&jw, "value", value);
>         jw_end(&jw);
> diff --git a/trace2/tr2_tgt_normal.c b/trace2/tr2_tgt_normal.c
> index c42fbade7f..69f8033077 100644
> --- a/trace2/tr2_tgt_normal.c
> +++ b/trace2/tr2_tgt_normal.c
> @@ -298,8 +298,11 @@ static void fn_param_fl(const char *file, int line, const char *param,
>                         const char *value)
>  {
>         struct strbuf buf_payload = STRBUF_INIT;
> +       enum config_scope scope = current_config_scope();
> +       const char *scope_name = config_scope_name(scope);
>
> -       strbuf_addf(&buf_payload, "def_param %s=%s", param, value);
> +       strbuf_addf(&buf_payload, "def_param scope:%s %s=%s", scope_name, param,
> +                   value);
>         normal_io_write_fl(file, line, &buf_payload);
>         strbuf_release(&buf_payload);
>  }
> diff --git a/trace2/tr2_tgt_perf.c b/trace2/tr2_tgt_perf.c
> index a1eff8bea3..8cb792488c 100644
> --- a/trace2/tr2_tgt_perf.c
> +++ b/trace2/tr2_tgt_perf.c
> @@ -441,12 +441,17 @@ static void fn_param_fl(const char *file, int line, const char *param,
>  {
>         const char *event_name = "def_param";
>         struct strbuf buf_payload = STRBUF_INIT;
> +       struct strbuf scope_payload = STRBUF_INIT;
> +       enum config_scope scope = current_config_scope();
> +       const char *scope_name = config_scope_name(scope);
>
>         strbuf_addf(&buf_payload, "%s:%s", param, value);
> +       strbuf_addf(&scope_payload, "%s:%s", "scope", scope_name);
>
> -       perf_io_write_fl(file, line, event_name, NULL, NULL, NULL, NULL,
> -                        &buf_payload);
> +       perf_io_write_fl(file, line, event_name, NULL, NULL, NULL,
> +                        scope_payload.buf, &buf_payload);
>         strbuf_release(&buf_payload);
> +       strbuf_release(&scope_payload);
>  }
>
>  static void fn_repo_fl(const char *file, int line,
>
> Am I understand accurately?
> Thanks.

Yes, exactly! That makes it much clearer what the functional change was
about, i.e. we can see what parts of the trace are now different (the
scope is added to the trace).


  reply	other threads:[~2022-07-19 11:54 UTC|newest]

Thread overview: 128+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-24 11:43 [PATCH v1 0/3] trace2 output for bitmap decision path Teng Long
2022-03-24 11:43 ` [PATCH v1 1/3] pack-bitmap.c: use "ret" in "open_midx_bitmap()" Teng Long
2022-03-24 19:11   ` Taylor Blau
2022-03-28  7:59     ` [PATCH v1 1/3] pack-bitmap.c: use "ret" in "open_midx_bitmap() Teng Long
2022-03-30  2:39       ` Taylor Blau
2022-03-24 11:44 ` [PATCH v1 2/3] pack-bitmap.c: add "break" statement in "open_pack_bitmap()" Teng Long
2022-03-24 18:40   ` Junio C Hamano
2022-03-24 19:06     ` Taylor Blau
2022-03-24 19:03   ` Taylor Blau
2022-03-29  2:49     ` Teng Long
2022-03-30  2:55       ` Taylor Blau
2022-03-30  7:32         ` Teng Long Teng Long
2022-03-30 13:17           ` Ævar Arnfjörð Bjarmason
2022-03-24 11:44 ` [PATCH v1 3/3] bitmap: add trace outputs during open "bitmap" file Teng Long
2022-03-24 18:42   ` Junio C Hamano
2022-03-24 13:22 ` [PATCH v1 0/3] trace2 output for bitmap decision path Ævar Arnfjörð Bjarmason
2022-03-29  7:38   ` Teng Long Teng Long
2022-03-29  8:54     ` Ævar Arnfjörð Bjarmason
2022-04-21 13:26 ` [PATCH v2 0/5] trace2 output for bitmap decision path Teng Long
2022-04-21 13:26   ` [PATCH v2 1/5] pack-bitmap.c: continue looping when first MIDX bitmap is found Teng Long
2022-05-11 21:31     ` Taylor Blau
2022-04-21 13:26   ` [PATCH v2 2/5] pack-bitmap.c: rename "idx_name" to "bitmap_name" Teng Long
2022-05-11 21:31     ` Taylor Blau
2022-04-21 13:26   ` [PATCH v2 3/5] pack-bitmap.c: make warnings more detailed when opening bitmap Teng Long
2022-04-21 17:25     ` Taylor Blau
2022-05-06  9:08       ` Teng Long
2022-04-21 13:26   ` [PATCH v2 4/5] bitmap: add trace2 outputs during open "bitmap" file Teng Long
2022-04-21 15:51     ` Ævar Arnfjörð Bjarmason
2022-05-06 11:27       ` Teng Long
2022-05-06 11:53       ` Teng Long
2022-04-21 16:32     ` Jeff Hostetler
2022-05-06 12:43       ` Teng Long
2022-05-10 20:47         ` Jeff Hostetler
2022-04-21 13:26   ` [PATCH v2 5/5] pack-bitmap.c: using error() instead of silently returning -1 Teng Long
2022-04-21 15:41     ` Ævar Arnfjörð Bjarmason
2022-05-06 12:55       ` Teng Long
2022-06-12  7:44   ` [PATCH v3 0/5] Teng Long
2022-06-12  7:44     ` [PATCH v3 1/5] pack-bitmap.c: continue looping when first MIDX bitmap is found Teng Long
2022-06-12  7:44     ` [PATCH v3 2/5] pack-bitmap.c: rename "idx_name" to "bitmap_name" Teng Long
2022-06-12  7:44     ` [PATCH v3 3/5] pack-bitmap.c: make warnings support i18N when opening bitmap Teng Long
2022-06-12  7:44     ` [PATCH v3 4/5] pack-bitmap.c: using error() instead of silently returning -1 Teng Long
2022-06-14  1:15       ` Taylor Blau
2022-06-20 13:17         ` Teng Long
2022-06-12  7:44     ` [PATCH v3 5/5] bitmap: add trace2 outputs during open "bitmap" file Teng Long
2022-06-13 20:59       ` Junio C Hamano
2022-06-20 13:32         ` Teng Long
2022-06-14  1:40       ` Taylor Blau
2022-06-21  6:58         ` Teng Long
2022-06-22 12:51       ` Jeff Hostetler
2022-06-23  9:38         ` Teng Long
2022-06-23 15:14           ` Jeff Hostetler
2022-06-24  8:27             ` [PATCH v3 5/5] bitmap: add trace2 outputs during open "bitmap" Teng Long
2022-06-21 13:25     ` [PATCH v3 0/5] trace2 output for bitmap decision path Teng Long
2022-06-21 13:25       ` [PATCH v3 1/5] pack-bitmap.c: continue looping when first MIDX bitmap is found Teng Long
2022-06-21 13:25       ` [PATCH v3 2/5] pack-bitmap.c: rename "idx_name" to "bitmap_name" Teng Long
2022-06-21 13:25       ` [PATCH v3 3/5] pack-bitmap.c: make warnings support i18N when opening bitmap Teng Long
2022-06-21 13:25       ` [PATCH v3 4/5] pack-bitmap.c: using error() instead of silently returning -1 Teng Long
2022-06-21 13:25       ` [PATCH v3 5/5] bitmap: add trace2 outputs during open "bitmap" file Teng Long
2022-06-22 13:04         ` Jeff Hostetler
2022-06-22 15:12           ` Junio C Hamano
2022-06-28  8:17       ` [PATCH v5 0/5] tr2: avoid to print "interesting" config repeatedly Teng Long
2022-06-28  8:17         ` [PATCH v5 1/5] pack-bitmap.c: continue looping when first MIDX bitmap is found Teng Long
2022-06-28  8:17         ` [PATCH v5 2/5] pack-bitmap.c: rename "idx_name" to "bitmap_name" Teng Long
2022-06-28  8:17         ` [PATCH v5 3/5] pack-bitmap.c: using error() instead of silently returning -1 Teng Long
2022-06-28 18:04           ` Junio C Hamano
2022-07-05  9:04             ` Teng Long
2022-07-05 18:23               ` Junio C Hamano
2022-06-28  8:17         ` [PATCH v5 4/5] pack-bitmap.c: retrieve missing i18n translations Teng Long
2022-06-28  8:58           ` Ævar Arnfjörð Bjarmason
2022-06-28 17:28             ` Eric Sunshine
2022-07-06 14:19               ` Teng Long
2022-07-06 14:06             ` Teng Long
2022-06-28 18:07           ` Junio C Hamano
2022-07-07 11:59             ` Teng Long
2022-07-07 16:45               ` Junio C Hamano
2022-07-11 11:04                 ` Teng Long
2022-06-28  8:17         ` [PATCH v5 5/5] tr2: avoid to print "interesting" config repeatedly Teng Long
2022-06-28  9:13           ` Ævar Arnfjörð Bjarmason
2022-06-28 18:12             ` Junio C Hamano
2022-07-01 14:31               ` Jeff Hostetler
2022-07-11  4:11                 ` Teng Long
2022-07-11  3:51             ` Teng Long
2022-07-11 12:43         ` [PATCH v6 0/7] trace2: dump scope when print "interesting" config Teng Long
2022-07-11 12:43           ` [PATCH v6 1/7] clean: fixed issues related to text output format Teng Long
2022-07-11 21:08             ` Junio C Hamano
2022-07-13 11:44               ` Teng Long
2022-07-11 12:43           ` [PATCH v6 2/7] pack-bitmap.c: mark more strings for translations Teng Long
2022-07-11 12:43           ` [PATCH v6 3/7] pack-bitmap.c: rename "idx_name" to "bitmap_name" Teng Long
2022-07-11 12:44           ` [PATCH v6 4/7] pack-bitmap.c: don't ignore ENOENT silently Teng Long
2022-07-11 14:38             ` Ævar Arnfjörð Bjarmason
2022-07-13 14:14               ` Teng Long
2022-07-11 21:22             ` Junio C Hamano
2022-07-14 15:25               ` Teng Long
2022-07-11 12:44           ` [PATCH v6 5/7] pack-bitmap.c: using error() instead of silently returning -1 Teng Long
2022-07-11 14:53             ` Ævar Arnfjörð Bjarmason
2022-07-15  2:34               ` Teng Long
2022-07-11 12:44           ` [PATCH v6 6/7] pack-bitmap.c: continue looping when first MIDX bitmap is found Teng Long
2022-07-11 12:44           ` [PATCH v6 7/7] tr2: dump names if config exist in multiple scopes Teng Long
2022-07-11 14:40             ` Ævar Arnfjörð Bjarmason
2022-07-11 19:19             ` Jeff Hostetler
2022-07-11 14:59           ` [PATCH v6 0/7] trace2: dump scope when print "interesting" config Ævar Arnfjörð Bjarmason
2022-07-18  8:36             ` Teng Long
2022-07-18 16:45           ` [PATCH v7 " Teng Long
2022-07-18 16:46             ` [PATCH v7 1/7] pack-bitmap.c: fix formatting of error messages Teng Long
2022-07-18 16:46             ` [PATCH v7 2/7] pack-bitmap.c: mark more strings for translations Teng Long
2022-07-18 16:46             ` [PATCH v7 3/7] pack-bitmap.c: rename "idx_name" to "bitmap_name" Teng Long
2022-07-18 16:46             ` [PATCH v7 4/7] pack-bitmap.c: do not ignore error when opening a bitmap file Teng Long
2022-07-18 16:46             ` [PATCH v7 5/7] pack-bitmap.c: using error() instead of silently returning -1 Teng Long
2022-07-18 16:46             ` [PATCH v7 6/7] pack-bitmap.c: continue looping when first MIDX bitmap is found Teng Long
2022-07-18 16:46             ` [PATCH v7 7/7] tr2: dump names if config exist in multiple scopes Teng Long
2022-07-18 20:13               ` Jeff Hostetler
2022-07-19  7:40                 ` tenglong.tl
2022-07-19 21:03               ` Junio C Hamano
2022-07-20 12:48                 ` tenglong.tl
2022-07-18 18:57             ` [PATCH v7 0/7] trace2: dump scope when print "interesting" config Junio C Hamano
2022-07-18 19:07               ` Ævar Arnfjörð Bjarmason
2022-07-19 11:26                 ` tenglong.tl
2022-07-19 11:42                   ` Ævar Arnfjörð Bjarmason [this message]
2022-07-19 12:34                     ` tenglong.tl
2022-07-21  9:05             ` [PATCH v8 0/6] pack-bitmap.c: optimize error messages tenglong.tl
2022-07-21  9:05               ` [PATCH v8 1/6] pack-bitmap.c: fix formatting of " tenglong.tl
2022-07-21  9:05               ` [PATCH v8 2/6] pack-bitmap.c: mark more strings for translations tenglong.tl
2022-07-21  9:05               ` [PATCH v8 3/6] pack-bitmap.c: rename "idx_name" to "bitmap_name" tenglong.tl
2022-07-21  9:05               ` [PATCH v8 4/6] pack-bitmap.c: do not ignore error when opening a bitmap file tenglong.tl
2022-07-21  9:05               ` [PATCH v8 5/6] pack-bitmap.c: using error() instead of silently returning -1 tenglong.tl
2022-07-21  9:05               ` [PATCH v8 6/6] pack-bitmap.c: continue looping when first MIDX bitmap is found tenglong.tl
2022-07-21 23:01               ` [PATCH v8 0/6] pack-bitmap.c: optimize error messages Junio C Hamano
2022-07-22  6:17                 ` tenglong.tl

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=220719.86tu7duxl3.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=derrickstolee@github.com \
    --cc=dyroneteng@gmail.com \
    --cc=git@jeffhostetler.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    --cc=tenglong.tl@alibaba-inc.com \
    /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).