diff mbox series

[v4,01/22] fsck.h: update FSCK_OPTIONS_* for object_name

Message ID 20210316161738.30254-2-avarab@gmail.com (mailing list archive)
State New, archived
Headers show
Series fsck: API improvements | expand

Commit Message

Ævar Arnfjörð Bjarmason March 16, 2021, 4:17 p.m. UTC
Add the object_name member to the initialization macro. This was
omitted in 7b35efd734e (fsck_walk(): optionally name objects on the
go, 2016-07-17) when the field was added.

Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
---
 fsck.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Junio C Hamano March 17, 2021, 6:35 p.m. UTC | #1
Ævar Arnfjörð Bjarmason  <avarab@gmail.com> writes:

> Add the object_name member to the initialization macro. This was
> omitted in 7b35efd734e (fsck_walk(): optionally name objects on the
> go, 2016-07-17) when the field was added.

While this does not hurt, as the missing one was and is at the end
of the struct members, this has no effect.  As you'll be rewriting
everything into designated initializers anyway, does it matter, I
have to wonder (it would affect your commit count karma, but you
already have enough of them ;-)?

>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
>  fsck.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fsck.h b/fsck.h
> index 733378f126..2274843ba0 100644
> --- a/fsck.h
> +++ b/fsck.h
> @@ -43,8 +43,8 @@ struct fsck_options {
>  	kh_oid_map_t *object_names;
>  };
>  
> -#define FSCK_OPTIONS_DEFAULT { NULL, fsck_error_function, 0, NULL, OIDSET_INIT }
> -#define FSCK_OPTIONS_STRICT { NULL, fsck_error_function, 1, NULL, OIDSET_INIT }
> +#define FSCK_OPTIONS_DEFAULT { NULL, fsck_error_function, 0, NULL, OIDSET_INIT, NULL }
> +#define FSCK_OPTIONS_STRICT { NULL, fsck_error_function, 1, NULL, OIDSET_INIT, NULL }
>  
>  /* descend in all linked child objects
>   * the return value is:
Johannes Schindelin March 19, 2021, 2:43 p.m. UTC | #2
Hi Ævar,

just a general note: this patch, which is the first of v4, is marked as
replying to the cover letter of v3. That feels quite odd. If you use
threading, why not let it reply to the cover letter of the same patch
series iteration?

In other words, would you mind using the `--thread=shallow` option in the
future, for better structuring on the mailing list?

Thanks,
Johannes

On Tue, 16 Mar 2021, Ævar Arnfjörð Bjarmason wrote:

> Add the object_name member to the initialization macro. This was
> omitted in 7b35efd734e (fsck_walk(): optionally name objects on the
> go, 2016-07-17) when the field was added.
>
> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
> ---
>  fsck.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fsck.h b/fsck.h
> index 733378f126..2274843ba0 100644
> --- a/fsck.h
> +++ b/fsck.h
> @@ -43,8 +43,8 @@ struct fsck_options {
>  	kh_oid_map_t *object_names;
>  };
>
> -#define FSCK_OPTIONS_DEFAULT { NULL, fsck_error_function, 0, NULL, OIDSET_INIT }
> -#define FSCK_OPTIONS_STRICT { NULL, fsck_error_function, 1, NULL, OIDSET_INIT }
> +#define FSCK_OPTIONS_DEFAULT { NULL, fsck_error_function, 0, NULL, OIDSET_INIT, NULL }
> +#define FSCK_OPTIONS_STRICT { NULL, fsck_error_function, 1, NULL, OIDSET_INIT, NULL }
>
>  /* descend in all linked child objects
>   * the return value is:
> --
> 2.31.0.260.g719c683c1d
>
>
Ævar Arnfjörð Bjarmason March 20, 2021, 9:16 a.m. UTC | #3
On Fri, Mar 19 2021, Johannes Schindelin wrote:

> Hi Ævar,
>
> just a general note: this patch, which is the first of v4, is marked as
> replying to the cover letter of v3. That feels quite odd. If you use
> threading, why not let it reply to the cover letter of the same patch
> series iteration?
>
> In other words, would you mind using the `--thread=shallow` option in the
> future, for better structuring on the mailing list?

Not at all, I've set it in my config now.

I've just been using the default configuration of format-patch
--in-reply-to --cover-letter && send-email *.patch all this time.

Looking around at other patch submissions (aside from GGG) this seems to
be the norm though, but isn't documented in SubmittingPatches
etc. AFAICT.

So I wonder if I'm using some different process from the norm, or if
most everyone else is just looking carefully at Message-ID/In-Reply-To
norms before sending...

> On Tue, 16 Mar 2021, Ævar Arnfjörð Bjarmason wrote:
>
>> Add the object_name member to the initialization macro. This was
>> omitted in 7b35efd734e (fsck_walk(): optionally name objects on the
>> go, 2016-07-17) when the field was added.
>>
>> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
>> ---
>>  fsck.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/fsck.h b/fsck.h
>> index 733378f126..2274843ba0 100644
>> --- a/fsck.h
>> +++ b/fsck.h
>> @@ -43,8 +43,8 @@ struct fsck_options {
>>  	kh_oid_map_t *object_names;
>>  };
>>
>> -#define FSCK_OPTIONS_DEFAULT { NULL, fsck_error_function, 0, NULL, OIDSET_INIT }
>> -#define FSCK_OPTIONS_STRICT { NULL, fsck_error_function, 1, NULL, OIDSET_INIT }
>> +#define FSCK_OPTIONS_DEFAULT { NULL, fsck_error_function, 0, NULL, OIDSET_INIT, NULL }
>> +#define FSCK_OPTIONS_STRICT { NULL, fsck_error_function, 1, NULL, OIDSET_INIT, NULL }
>>
>>  /* descend in all linked child objects
>>   * the return value is:
>> --
>> 2.31.0.260.g719c683c1d
>>
>>
Junio C Hamano March 20, 2021, 8:04 p.m. UTC | #4
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

>> In other words, would you mind using the `--thread=shallow` option in the
>> future, for better structuring on the mailing list?
>
> Not at all, I've set it in my config now.
>
> I've just been using the default configuration of format-patch
> --in-reply-to --cover-letter && send-email *.patch all this time.
> ...
> So I wonder if I'm using some different process from the norm, or if
> most everyone else is just looking carefully at Message-ID/In-Reply-To
> norms before sending...

Interesting.  I always let send-email assign the message IDs and
haven't used --thread=<any> option at all.  In other words, my
format-patch output files have no message IDs in them or In-reply-to
header fields.  That in turn means that in-reply-to is decided not
when format-patch is run, but when send-email sends things out, it
gives them the ids and structures the in-reply-to chains.

I guess we have too much flexibility in our tooling X-<.
diff mbox series

Patch

diff --git a/fsck.h b/fsck.h
index 733378f126..2274843ba0 100644
--- a/fsck.h
+++ b/fsck.h
@@ -43,8 +43,8 @@  struct fsck_options {
 	kh_oid_map_t *object_names;
 };
 
-#define FSCK_OPTIONS_DEFAULT { NULL, fsck_error_function, 0, NULL, OIDSET_INIT }
-#define FSCK_OPTIONS_STRICT { NULL, fsck_error_function, 1, NULL, OIDSET_INIT }
+#define FSCK_OPTIONS_DEFAULT { NULL, fsck_error_function, 0, NULL, OIDSET_INIT, NULL }
+#define FSCK_OPTIONS_STRICT { NULL, fsck_error_function, 1, NULL, OIDSET_INIT, NULL }
 
 /* descend in all linked child objects
  * the return value is: