Thank you all. I will try to carry forward a patch with this change and a hint about the recommended maintenance approach for longer runs. On Tue, Dec 6, 2022 at 11:41 PM Jeff Hostetler <git@xxxxxxxxxxxxxxxxx> wrote: > > > > On 12/6/22 1:03 PM, Derrick Stolee wrote: > > On 12/1/2022 7:25 AM, Tao Klerks wrote: > >> But my *question* is: Does anyone know where I could/should look to > >> understand why the GC was happening in the foreground, even though the > >> message says it will run in the background? > > > > On Windows, Git's foreground process cannot complete without also > > killing the background process. I'm not sure on the concrete details, > > but the lack of a background "git gc --auto" here is deliberate for > > that platform. > > Here the GC code uses `daemonize()`. On Posix this is a wrapper around > `fork()` where the parent exits and the child continues the computation > (without stdin/out). > > However, `daemonize()` just returns an ENOSYS on Windows, since Windows > doesn't have `fork()`. The net result is that the foreground process > falls thru and does the actual work. > > > [...] > > Instead, the modern recommendation for repositories where "git gc --auto" > > would be slow is to run "git maintenance start" which will schedule > > background maintenance jobs with the Windows scheduler. Those processes > > are built to do updates that are non-invasive to concurrent foreground > > processes. It also sets config to avoid "git gc --auto" commands at the > > end of foreground Git processes. > > > > See [1] for more details. > > > > [1] https://git-scm.com/docs/git-maintenance > > It is possible to do the GC in the background on Windows (using other > techniques), but I don't think it is worth the bother now that we have > `git maintenance` to handle it. > > And yes, AEvar's suggested fix for printing the correct error message > looks helpful. > > > Jeff
