git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] gc: introduce an --auto-exit-code option for undoing 3029970275

From
Jonathan Nieder <jrnieder@gmail.com>
Date
Oct 10, 2018, 22:25 UTC
Message-ID
<20181010222526.GC231512@aiede.svl.corp.google.com>
In-Reply-To
<87o9c1e9br.fsf@evledraar.gmail.com>
Ævar Arnfjörð Bjarmason wrote:
Show 5 quoted lines
> 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.

Show 7 quoted lines
> 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
Previous: Ævar Arnfjörð BjarmasonNext: Ævar Arnfjörð Bjarmason
Message 20 of 26 in “git svn clone/fetch hits issues with gc --auto”
  1. Martin LanghoffOct 9, 2018
  2. Eric WongOct 9, 2018
  3. Junio C HamanoOct 10, 2018
  4. Martin LanghoffOct 10, 2018
  5. Ævar Arnfjörð BjarmasonOct 10, 2018
  6. Martin LanghoffOct 10, 2018
  7. Ævar Arnfjörð BjarmasonOct 10, 2018
  8. Jonathan NiederOct 10, 2018
  9. Jeff KingOct 10, 2018
  10. gc: introduce an --auto-exit-code option for undoing 3029970275Ævar Arnfjörð Bjarmason, Oct 10, 2018
  11. Jeff KingOct 10, 2018
  12. Ævar Arnfjörð BjarmasonOct 10, 2018
  13. Jeff KingOct 11, 2018
  14. Jonathan NiederOct 10, 2018
  15. Ævar Arnfjörð BjarmasonOct 10, 2018
  16. Jonathan NiederOct 10, 2018
  17. Junio C HamanoOct 10, 2018
  18. Jonathan NiederOct 10, 2018
  19. Ævar Arnfjörð BjarmasonOct 10, 2018
  20. Jonathan NiederOct 10, 2018
  21. Ævar Arnfjörð BjarmasonOct 10, 2018
  22. Ævar Arnfjörð BjarmasonOct 10, 2018
  23. Junio C HamanoOct 10, 2018
  24. Ævar Arnfjörð BjarmasonOct 10, 2018
  25. Martin LanghoffOct 10, 2018
  26. Ævar Arnfjörð BjarmasonOct 10, 2018

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.