Re: Summary of core GIT while you are away.

From: Linus Torvalds <torvalds@osdl.org>
Date: May 26, 2005, 01:53 UTC
Message-ID: <Pine.LNX.4.58.0505251845270.2307@ppc970.osdl.org>
In-Reply-To: <7vzmuig561.fsf@assigned-by-dhcp.cox.net>

On Wed, 25 May 2005, Junio C Hamano wrote:

> 
> I haven't done anything about this yet.  I was kind of waiting
> for the blob retention API for "struct object" derivatives to
> come to the conclusion.

I decided on it, and it's a hacky (but reasonable) decision.

"parse_commit()" always retains the buffer for the commit. It's very commit-specific, since (a) that's the main data structure that you'd actually want to retain and (b) of all the core objects (ignoring tags) commits tend to be the smallest and fewest, so this fixed policy has the least impact memory-usage-wise.

If you want to free it, you can do

	free(commit->buffer);
	commit->buffer = NULL;

and you should be all good (but the only user I thought migh want to is "fsck", and that one doesn't need to, since it never calls "parse_commit()" at all - it calls "parse_commit_buffer()" which does _not_ do this, since the caller already knows the buffer and can choose to do it if it wants to.

Oh, thinking about that actually brings up a bug: mixing parse_commit() and parse_commit_buffer() is unsafe, since the state of the buffer is unclear. Normally that's ok, _except_ when we use just "parse_object()" (like we do in "lookup_commit_reference()"), when we really don't know. Hmm.

		Linus