Jonathan Tan <jonathanta...@google.com> writes: >> Hmph, remind me how old and/or new shallow cut-off points affect >> this traversal? In order to verify that everything above the new >> cut-off points, opt->shallow_file should be pointing at the new >> cut-off points, then we do the full sweep (without --not --all) to >> ensure we won't find missing or broken objects but still stop at the >> new cut-off points, and then only after check_connected() passes, >> update the shallow file to make new shallow cut-off points active >> (and if the traversal fails, then we do nto install the new shallow >> cut-off points)? > > That is the way it should work, but after thinking about it once more, I > realize that it isn't. > > opt->shallow_file is not set to anything. And fetch-pack updates the > shallow file by itself (at least, that is my understanding of > update_shallow() in fetch-pack.c) before fetch calls check_connected(), > meaning that if check_connected() fails, there is still no rollback of > the shallow file.
Ouch. We need to fix that; otherwise, a broken server will keep giving you a corrupt repository even with this fix, no?
