Re: Auto packing the repository - foreground or background in Windows?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux