Robert Coup <robert.coup@xxxxxxxxxxxxxxx> writes: > Basically --refetch was originally designed to send no 'have's during a fetch, > the original motivation being changing a partial clone filter and fetching > all the newly-applicable trees & blobs in a single transfer. > ... > If a commit is missing that's one way to fix > it, but it's a pretty nuclear option: feels like your option iv (terminate with > an error) leading to fsck invoking/suggesting --refetch might avoid > unintentionally recloning the entire repo. > ... > In my original RFC [3], Jonathan Tan suggested that --refetch could be useful > to repair missing objects like this, but it was out of scope for me at the time. > But maybe there's a way to improve it for this sort of case? > > [3] https://lore.kernel.org/git/20220202185957.1928631-1-jonathantanmy@xxxxxxxxxx/ Thanks for your comments on the original story behind that option. > I presume there wasn't an obvious/related cause for commit 6aaaca to go missing > in the first place? Emily had this after the three-dash line a: That commit object went missing as a byproduct of this partial clone gc issue that Calvin, Jonathan, Han Young, and others have been investigating: https://lore.kernel.org/git/20241001191811.1934900-1-calvinwan@xxxxxxxxxx/ IOW, I think how the lossage was caused is well understood by now. Thanks.
