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