All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Taylor Blau <me@ttaylorr.com>,
	 git@vger.kernel.org,  Scott Leggett <scott@sl.id.au>
Subject: Re: [PATCH] commit-graph: retain commit slab when closing NULL commit_graph
Date: Wed, 10 Jan 2024 08:38:18 -0800	[thread overview]
Message-ID: <xmqq34v5dtz9.fsf@gitster.g> (raw)
In-Reply-To: <20240110113914.GE16674@coredump.intra.peff.net> (Jeff King's message of "Wed, 10 Jan 2024 06:39:14 -0500")

Jeff King <peff@peff.net> writes:

> I think a simpler solution would be that upon clearing the slab, we
> either "finish" each commit (filling in the maybe_tree field) or
> "unparse" it (unsetting the parsed flag, and then doing a regular and/or
> graph lookup if it is accessed again later).

Wow, that's clever.

> It should be easy-ish to iterate through the slab and look at the
> commits that are mentioned in it. Though maybe not? Each commit knows
> its slab-id, but I'm not sure if we have a master list of commits to go
> the other way.

We have table of all in-core objects, don't we?

> +	 * This will throw away the parents list, which is potentially sketchy.
> +	 * A better version of this would just unset commit->object.parsed
> +	 * and then do a minimal version of parse_commit() that _just_ loads
> +	 * the tree data (and/or graph position if available).

Yeah, it is a concern that we may be working with an in-core commit
object whose parent list has already been rewritten during revision
traversal.  Well thought out.

> +	 *
> +	 * Naturally we'd need to drop the "const" from our commit above, too.
> +	 */
> +	unparse_commit(r, &commit->object.oid);
> +	repo_parse_commit(r, commit);
> +
>  	return NULL;
>  }
>  
> I dunno. I do feel like this is a lurking maintenance headache, and
> might even be a triggerable bug. But without knowing of a way that it
> happens in the current code base, it feels like it would be easy to make
> things worse rather than better.

Unfortunately I share the feeling X-<.

Thanks.

  reply	other threads:[~2024-01-10 16:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-05  5:41 [PATCH] commit-graph: retain commit slab when closing NULL commit_graph Jeff King
2024-01-05 17:07 ` Taylor Blau
2024-01-10 11:39   ` Jeff King
2024-01-10 16:38     ` Junio C Hamano [this message]
2024-01-11  7:53       ` Jeff King
2024-01-11 18:35         ` Junio C Hamano
2024-01-05 19:56 ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq34v5dtz9.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=me@ttaylorr.com \
    --cc=peff@peff.net \
    --cc=scott@sl.id.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.