Re: [RFC PATCH] promisor-remote: always JIT fetch with --refetch
Robert Coup <robert.coup@koordinates.com> writes:
Show 14 quoted lines
> 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@google.com/
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@google.com/
IOW, I think how the lossage was caused is well understood by now.
Thanks.
Junio C Hamano <gitster@pobox.com>