Message ID | cover-00.17-0000000000-20210520T111610Z-avarab@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | fsck: better "invalid object" error reporting | expand |
> So in some senes this matters to nobody, but I'm doing this as part of > general changes I've been pushing to make fsck/gc error reporting more > graceful, and errors more recoverable. We now have a few more places > in object-file.c where we don't just die(), but properly return > API-like return codes/data to the caller instead. Well, I guess it's useful if somehow your repository got corrupted, and you want to pinpoint where it occurred. > Ævar Arnfjörð Bjarmason (17): > fsck tests: refactor one test to use a sub-repo > fsck tests: add test for fsck-ing an unknown type > cat-file tests: test for missing object with -t and -s > cat-file tests: test that --allow-unknown-type isn't on by default > rev-list tests: test for behavior with invalid object types > cat-file tests: add corrupt loose object test > cat-file tests: test for current --allow-unknown-type behavior > cache.h: move object functions to object-store.h > object-file.c: make parse_loose_header_extended() public > object-file.c: add missing braces to loose_object_info() > object-file.c: stop dying in parse_loose_header() > object-file.c: return -2 on "header too long" in unpack_loose_header() > object-file.c: return -1, not "status" from unpack_loose_header() > fsck: don't hard die on invalid object types > object-store.h: move read_loose_object() below 'struct object_info' > fsck: report invalid types recorded in objects > fsck: report invalid object type-path combinations My main comment as a reviewer is I think that there are a lot of unrelated changes in this patch set - in particular, the first 7 tests (1 fsck test that refactors something unrelated, 1 fsck test that I presume will be overridden later, and 5 tests for other commands unrelated to fsck). I'll also give comments on individual patches.
Jonathan Tan <jonathantanmy@google.com> writes: > My main comment as a reviewer is I think that there are a lot of > unrelated changes in this patch set ... Thanks for reviewing. I share the same feeling, not specifically about this series, but I find that "doing too many while-at-it changes" is shared among the topics by the same author, and I often wish each topic were more focused.
Junio C Hamano wrote: > Jonathan Tan <jonathantanmy@google.com> writes: > > > My main comment as a reviewer is I think that there are a lot of > > unrelated changes in this patch set ... > > Thanks for reviewing. I share the same feeling, not specifically > about this series, but I find that "doing too many while-at-it > changes" is shared among the topics by the same author, and I often > wish each topic were more focused. The author has a name. I understand why as a reviewer you want a small patch series, but as a patch-writer you want your code to land on master. Perhaps if there was an actual incentive to split a patch series more people would do so, but in my personal experience that has not been the case. If I had to name the reason why some of my patches have landed on master I would say it's *arbitrary*. Maybe you catch reviewers on a good mood, or the maintainer in-between release candidates. But regardless of the actual reason, patch-series' size doesn't seem to be a huge factor. As exhibit I can five two patch-series of mine: 1. https://lore.kernel.org/git/20201223144845.143039-1-felipe.contreras@gmail.com/ 2. https://lore.kernel.org/git/20210426161458.49860-1-felipe.contreras@gmail.com/ The first one is 4 patches. The second one is 43. The second one receved feedback from the maintainer. The first one was complerely ignored. Neither were acceped. This is not intended to point fingers at anyone, merely to state the a mathematical fact. Splitting a patch series is usually more work. If there's no real incentive for a submitter to do so, why would she/he? Cheers.