Ævar Arnfjörð Bjarmason wrote: > Which is what I'm doing by running "gc --auto" across a set of servers > and looking at the exit code. If it's been failing I get an error, if > there's no need to gc nothing happens, and if it hasn't been failing and > it just so happens that it's time to GC then fine, now was as good a > time as any. For this, a simple "git gc --detached-status" would work. It sounds like the bonus gc --auto run was a side effect instead of being a requirement. > So if we assume that for the sake of argument there's no point in a > --detached-status either. My only reason for ever caring about that > status is when I run "gc --auto" and it says it can't fork() itself so > it fails. Since I'm using "gc --auto" I have zero reason to even ask > that question unless I'm OK with kicking off a gc run as a side-effect, > so why split up the two? It just introduces a race condition for no > benefit. What I am trying to do is design an interface which is simple to explain in the manual. The existing "git gc --auto" interface since detaching was introduced is super confusing to me, so I'm going through the thought exercise of "If we were starting over, what would we build instead?" Part of the answer to that question might include a --report-from-the-last-time-you-detached option. I'm still failing to come up of a case where the answer to that question would include a --report-from-the-last-time-you-detached-and-if-it-went-okay\ -then-run-another-detached-gc option. In other words, I think our disconnect is that you are describing things in terms of "I have been happy with the existing git gc --auto detaching behavior, so how can we maintain something as close as possible to that"? And I am trying to describe things in terms of "What is the simplest, most maintainable, and easiest to explain way to keep Ævar's servers working well"? Jonathan
