On 11/10/2021 2:47 PM, Junio C Hamano wrote: > "Derrick Stolee via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > >> This one is really tricky because we can't notice anything is wrong >> without running git maintenance start or git maintenance stop >> interactively on macOS. The tests pass just fine because the UI alert >> gets automatically ignored during the test suite. >> >> This is a bit of a half-fix: it avoids the UI alert, but has a corner >> case of not un-doing the cron schedule if a user manages to select it >> (under suitable permissions such that it succeeds). For the purpose of >> the timing of the release, I think this is an appropriate hedge. > > Reverting the "git maintainance run --scheduler=<scheduler>" topic > altogether to give us time to stop and think may be another obvious > option, but it probably is OK to tell macOS users that they may have > cron but Git won't work with their cron with this patch. > > In any case, let's leave it (slightly) broken for macOS folks by > applying this quickfix. I agree that we don't need to revert the topic. > I was puzzled by the lack of a call to validate_scheduler() at the > very beginning of resolve_scheduler(), by the way. Or even earlier > during the verification of the command line options. I wonder if > on macOS, --scheduler=nosuch and --scheduler=cron should behave the > same way, both saying "unrecognized", instead of saying that only to > the former and "not available" to the latter. It's a bit strange, but the crux is that selecting --scheduler=X makes the 'X' scheduler pass through the 'enable' path, while the rest of the "available" schedulers goes through the 'disable' path. This UI prompt occurs because we are trying to 'disable' cron before enabling launchctl. I think the biggest issue is how macOS uses non-standard ways of requesting user permissions, because if 'crontab' simply exited with a non-zero status, there would be no work to do here. Because of that, I think we will always need to tiptoe around cron on macOS. Thanks, -Stolee
