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

Re: [PATCH 2/2] rerere: fix overeager gc

From
Junio C Hamano <gitster@pobox.com>
Date
Jul 14, 2010, 16:23 UTC
Message-ID
<7v1vb6yqve.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20100714121925.GG15270@neumann>
SZEDER Gábor <szeder@ira.uka.de> writes:
Show 15 quoted lines
> On Mon, Jul 12, 2010 at 05:40:11PM -0700, Junio C Hamano wrote:
>> SZEDER Gábor <szeder@ira.uka.de> writes:
>> > +static time_t rerere_last_used_at(const char *name)
>> > +{
>> > +	struct stat st;
>> > +	return stat(rerere_path(name, "postimage"), &st) ? (time_t) 0 : st.st_mtime;
>> > +}
>> 
>> Doesn't has_rerere_resolution() already do a stat on this path?  There are
>> only two allers of the function so it would probably make sense to pass a
>> pointer to struct stat from the caller to avoid one extra call to stat.
>
> rerere_last_used_at() returns 0 when the stat() on 'postimage' fails,
> exactly like has_rerere_resolution().  Consequently, we can use
> rerere_last_used_at() to determine whether a resolution exists, too.

"When was this last used?" is answered with "infinitely long time ago" for an item that does not exist. Between the ones that have never been resolved (i.e. no "postimage") and the ones that have not been used for a long time, there is no material difference in the expiration, as long as "long time" exceeds rerere-unresolved. Ok; I can see the logic in that.

I wonder if swapping the order of things to check may make it easier to read, though. If it was used, we want to compare gc.rerereresolved with that timestamp, and otherwise we want to compare gc.rerereunresolved with the timestamp of the creation. I.e. something like this...

 builtin/rerere.c |   14 +++++++-------
 1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/builtin/rerere.c b/builtin/rerere.c
index 7e45afe..6d1b580 100644
--- a/builtin/rerere.c
+++ b/builtin/rerere.c
@@ -59,16 +59,16 @@ static void garbage_collect(struct string_list *rr)
 	while ((e = readdir(dir))) {
 		if (is_dot_or_dotdot(e->d_name))
 			continue;
-		then = rerere_created_at(e->d_name);
-		if (!then)
-			continue;
-		if (has_rerere_resolution(e->d_name)) {
-			then = rerere_last_used_at(e->d_name);
+
+		then = rerere_last_used_at(e->d_name);
+		if (then) {
+			cutoff = cutoff_resolve;
+		} else {
+			then = rerere_created_at(e->d_name);
 			if (!then)
 				continue;
-			cutoff = cutoff_resolve;
-		} else
 			cutoff = cutoff_noresolve;
+		}
 		if (then < now - cutoff * 86400)
 			string_list_append(e->d_name, &to_remove);
 	}
Previous: SZEDER GáborNext: SZEDER Gábor
Message 22 of 24 in “rerere: fix overeager gc”
  1. rerere: fix overeager gcSZEDER Gábor, Jun 29, 2010
  2. Junio C HamanoJun 29, 2010
  3. Johannes SixtJun 30, 2010
  4. SZEDER GáborJun 30, 2010
  5. Junio C HamanoJun 30, 2010
  6. Johannes SixtJun 30, 2010
  7. rerere: fix overeager gcSZEDER Gábor, Jul 1, 2010
  8. Johannes SixtJul 1, 2010
  9. 1/2 mingw: utime() handles NULL times parameterSZEDER Gábor, Jul 1, 2010
  10. 1/2 mingw_utime(): handle NULL times parameterJohannes Sixt, Jul 1, 2010
  11. 2/2 rerere: fix overeager gcSZEDER Gábor, Jul 1, 2010
  12. Junio C HamanoJul 1, 2010
  13. Johannes SixtJul 2, 2010
  14. Junio C HamanoJul 2, 2010
  15. Johannes SixtJul 5, 2010
  16. rerere: fix overeager gcSZEDER Gábor, Jul 8, 2010
  17. Junio C HamanoJul 9, 2010
  18. 1/2 mingw_utime(): handle NULL times parameterSZEDER Gábor, Jul 12, 2010
  19. 2/2 rerere: fix overeager gcSZEDER Gábor, Jul 12, 2010
  20. Junio C HamanoJul 13, 2010
  21. SZEDER GáborJul 14, 2010
  22. Junio C HamanoJul 14, 2010
  23. SZEDER GáborJul 14, 2010
  24. Johannes SixtJul 8, 2010

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.