On Mon, Oct 04 2021, Junio C Hamano wrote: > * ab/fsck-unexpected-type (2021-10-01) 17 commits > - fsck: report invalid object type-path combinations > - fsck: don't hard die on invalid object types > - object-file.c: stop dying in parse_loose_header() > - object-file.c: return ULHR_TOO_LONG on "header too long" > - object-file.c: use "enum" return type for unpack_loose_header() > - object-file.c: simplify unpack_loose_short_header() > - object-file.c: make parse_loose_header_extended() public > - object-file.c: return -1, not "status" from unpack_loose_header() > - object-file.c: don't set "typep" when returning non-zero > - cat-file tests: test for current --allow-unknown-type behavior > - cat-file tests: add corrupt loose object test > - cat-file tests: test for missing/bogus object with -t, -s and -p > - cat-file tests: move bogus_* variable declarations earlier > - fsck tests: test for garbage appended to a loose object > - fsck tests: test current hash/type mismatch behavior > - fsck tests: refactor one test to use a sub-repo > - fsck tests: add test for fsck-ing an unknown type > > "git fsck" has been taught to report mismatch between expected and > actual types of an object better. > > Will merge to 'next'? I think it's ready, also noted last time around[1]. You had one question on the v10, which I hope I answered to your satisfaction at[2]. Note that Jeff's just-submitted cat-file series[3] will conflict with this, as they both adjust the same "garbage" object tests. The semantic conflict is minimal/none, but the textual one is probably annoying (e.g. his 1/5 uses a variable I split/renamed). Jeff: Depending on what Junio thinks of queuing ab/fsck-unexpected-type for next what do you think about rebasing your series on top, or perhaps take a look at the v10[4] of it/ack it in case that helps with that (since you've been looking at some related code just now...). 1. https://lore.kernel.org/git/87y27dq70e.fsf@xxxxxxxxxxxxxxxxxxx/ 2. https://lore.kernel.org/git/87sfxkpdqp.fsf@xxxxxxxxxxxxxxxxxxx/ 3. https://lore.kernel.org/git/YVy1sx8Xb1xMLFQT@xxxxxxxxxxxxxxxxxxxxxxx/ 4. https://lore.kernel.org/git/cover-v10-00.17-00000000000-20211001T091051Z-avarab@xxxxxxxxx/
