Re: [PATCH 2/3] path-walk: fix setup of pending objects
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Aug 20, 2025, 19:42 UTC
- Message-ID
- <c6ab0985-2a74-406b-9685-cc65f8748515@gmail.com>
- In-Reply-To
- <xmqqh5y1ak9o.fsf@gitster.g>
On 8/20/2025 3:02 PM, Junio C Hamano wrote:
Show 15 quoted lines
> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes: > >> The core problem here is that the "maybe_interesting" member of 'struct >> type_and_oid_list' is not initialized to '1'. This member was added in >> 6333e7ae0b (path-walk: mark trees and blobs as UNINTERESTING, >> 2024-12-20) in a way to help when creating packfiles for a small commit >> range using the sparse path algorithm (enabled by pack.useSparse=true). > > OK, in other words, the bug is fairly contained within the path-walk > traversal. We treat things as reachable not just from ref tips and > reflogs (where path-walk code can use the tree object to compute on > what pathname each blob comes from) and the main index array (that > has paths, even though it needs separate way to compute than those > for trees), but also from places like REUC and TREE extensions that > make associations between pathnames and objects. Are they also OK?
The key integration point is the "pending" list operating a bit different from walking directly from tags or commits. I was trying to reproduce the issue from all of those other sources before unlocking the "singleton" nature of the problem, and failed to do so.
The resolve-undo cache (REUC) is something that I had not tested previously. Adding "git rm --cached x/y" to the test in the previous case leads to the 'git fsck' call giving a "dangling blob" warning, so that could be an interesting way to strengthen the test. Thanks, -Stolee