Re: What's cooking in git.git (Mar 2021, #03; Wed, 10)

[Junio C Hamano <gitster@pobox.com>]

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

> On Thu, Mar 11 2021, Junio C Hamano wrote:
>
> Some notes, mostly on my own topics:

Thanks.

>> * ab/tests-cleanup-around-sha1 (2021-03-10) 4 commits
>>  - tests: get rid of $_x05 from the test suite
>>  - shortlog tests: rewrite to get rid of --abbrev=35 hardcoding
>>  - test-lib: remove unused $_x40 and $_z40 variables
>>  - git-bisect: remove unused SHA-1 $x40 shell variable
>
> FWIW (mostly for other readers) I suggested in
> https://lore.kernel.org/git/87tupigf02.fsf@evledraar.gmail.com/ just now
> that we drop 4/4.

I do not trust myself; we need to get 2&3 reviewed independently
before we can move beyond discarding the $_x05 step.


>> * ab/fsck-api-cleanup (2021-02-18) 10 commits
>>  - fsck.h: update FSCK_OPTIONS_* for object_name
>>  - fsck.c: give "FOREACH_MSG_ID" a more specific name
>>  - fsck.c: undefine temporary STR macro after use
>>  - fsck.c: call parse_msg_type() early in fsck_set_msg_type()
>>  - fsck.h: move FSCK_{FATAL,INFO,ERROR,WARN,IGNORE} into an enum
>>  - fsck.c: rename remaining fsck_msg_id "id" to "msg_id"
>>  - fsck.c: move definition of msg_id into append_msg_id()
>>  - fsck.c: rename variables in fsck_set_msg_type() for less confusion
>>  - fsck.h: use "enum object_type" instead of "int"
>>  - fsck.h: indent arguments to of fsck_set_msg_type
>>
>>  Preliminary fsck API clean-up.
>>
>>  Expecting a reroll.
>>  cf. <xmqqczwxc8bw.fsf@gitster.g>
>
> I think this note at least needs to be updated to say the re-roll exists
> at https://lore.kernel.org/git/20210306110439.27694-1-avarab@gmail.com/

Sure.  But consider anything outside 'next' would be the same as
"discarded" to get a fresh start after a release.

>> * ab/make-cocci-dedup (2021-03-05) 4 commits
>>  - Makefile/coccicheck: set SPATCH_BATCH_SIZE to 8
>>  - Makefile/coccicheck: allow for setting xargs concurrency
>>  - Makefile/coccicheck: speed up and fix bug with duplicate hunks
>>  - Makefile/coccicheck: add comment heading for all SPATCH flags
>>
>>  An attempt to speed up the coccicheck target with incorrect
>>  results.
>>
>>  A reroll exists to address correctness issue, but not picked up.
>
> Any reason for not picked up other than "rc period etc...".

As I always say, please don't read anything more than "I happen to
have seen it" in being in 'seen'.  And that does not even mean
everything I saw would be on 'seen'.  Especially during the
pre-release freeze.  I may have time to pick up a replacement for a
topic that is already in 'seen', to make sure there aren't unexpected
new conflicts I'll later have to resolve, and if it is too bad, I may
even drop the old iteration (because it is stale and a new one exists)
and the new iteration (because it may be fresher but does not work
well with others).

> I'm
> confident the patch at
> https://lore.kernel.org/git/20210306192525.15197-1-avarab@gmail.com/
> addresses the intra-series bug, and the whole thing solves outstanding
> bugs on master.

I recall seeing you use a new option to coccinelle that I did not
get any hit on my search engine in the updated series.  Is the world
ready for the thing?

>> * ab/unexpected-object-type (2021-03-08) 7 commits
>>  - tag: don't misreport type of tagged objects in errors
>>  - object tests: add test for unexpected objects in tags
>>  - object.c: add a utility function for "expected type X, got Y"
>>  - tree.c: fix misindentation in parse_tree_gently()
>>  - oid_object_info(): return "enum object_type"
>>  - object.c: make type_from_string() return "enum object_type"
>>  - object.c: refactor type_from_string_gently()
>>
>>  Error reporting upon object type mismatch has been improved
>>
>>  Looked good.
>
> It still loks scary to me :)

Yes, I do think it was a mistake to rewrite <0 with ==BAD in this
series, and I won't be marking it to be merged down anywhere until
that gets fixed.  There may be other issues that may have been
pointed out by others' reviews I am not aware of.

> But I've had no feedback on 7/7, which is the real meaty chang in the
> series:
> https://lore.kernel.org/git/20210308200426.21824-8-avarab@gmail.com/
>
> It would be nice to know if that's beacuse others have nothing to add,
> or it just hasn't been looked over.

Yes.

> Just a point of clarification, are all the "Will cook in 'next'" lines
> here to be read equivalently to "Unless something comes up, will be in
> the first major post-release merge down to master?".

It is equivalent to "Will merge to 'master'" outside the prerelease
freeze period.  Unless something comes up, this is on course to be
eventually in 'master'.

> I.e. no pre-release merge of next->master is expected.

In the pre-release period, the contributors are encouraged to
concentrate on finding and fixing potential regressions and on
perfecting those topics that are already cooking (in this order of
priority) to help prepare for a smooth launch of the upcoming
release and the start of the next cycle after that.  It is not the
time to send out brand new patches with the expectation to be in
'seen'.

>> * ab/pickaxe-pcre2 (2021-02-18) 24 commits
>>  ...
>>  Needs review.
>>  cf. <20210216115801.4773-1-avarab@gmail.com>
>
> If anyone would like faster pickaxe reviews of this would be most
> welcome. It's not faster yet with this, but it's the required prep work.
>
> Alternatively, what do you think about picking this up up to 15/22?:
> https://lore.kernel.org/git/20210216115801.4773-16-avarab@gmail.com/
>
> Up until that point it's all trivial code changes and testing.

I'd welcome replacement submission that has only patches with
reduced scope, but after the release please ;-).