Re: [PATCH 0/2] Fix background maintenance regression in Git 2.45.0
- From
Derrick Stolee <stolee@gmail.com>
- Date
- Jul 19, 2024, 16:20 UTC
- Message-ID
- <861420aa-e423-4475-8eba-8ec5187c52d4@gmail.com>
- In-Reply-To
- <xmqq34o5l8j7.fsf@gitster.g>
On 7/19/24 11:13 AM, Junio C Hamano wrote:
Show 26 quoted lines
> Derrick Stolee <stolee@gmail.com> writes: > >> On 7/18/24 5:57 PM, Junio C Hamano wrote: >>> "Derrick Stolee via GitGitGadget" <gitgitgadget@gmail.com> writes: >>> >>>> Here is an issue I noticed while exploring issues with my local copy of a >>>> large monorepo. I was intending to show some engineers how nice the objects >>>> were maintained by background maintenance, but saw hundreds of small >>>> pack-files that were up to two months old. This time matched when I upgraded >>>> to the microsoft/git fork that included the 2.45.0 release of Git. >>> I almost said "wow, perfect timing on the -rc1 day", but then >>> realized that this is not a regression during _this_ cycle, but a >>> cycle ago. >> >> I almost waited until after the release, but I wanted to put the >> information out there just in case you were interested in taking it >> into 2.46.0 or were planning on a 2.45.3. > > Yup, thanks but this is not exactly a repository breaking data > corruption bug, and did not look ultra urgent. Especially if we > want to pursue a solution that helps both expiring stale packs > better (which is what you are restoring) and making better delta > chain selection (which may be what you are losing) at the same time, > such a change could become a source of data corruption bug, so I'd > prefer to see it started early in a cycle, rather as a last-minute > "let's fix this too".
I agree with this assessment. The microsoft/git fork has taken the revert as users of that fork have a higher chance of being affected.
Thanks, -Stolee