Re: [PATCH] checkout: don't write merge results into the object database

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 15, 2017, 21:56 UTC
Message-ID: <xmqqefukzzik.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <f7d38553-484b-ee81-e059-2c737dad2bc4@web.de>

René Scharfe <l.s.r@web.de> writes:

Show 5 quoted lines

>> If it is a concern, I think it could be solved by "unpretending" after
>> our call to checkout_entry completes. That would need a new call in
>> sha1_file.c, but it should be easy to write.
>
> Good point; we'd accumulate fake entries that we'll never need again.

Hopefully we are not pretending to have the same object from two callsites; this one may knows the merged one no longer needs to be in core, but some other callsite wanted to pretend a blob with the same contents is in the object store, what happens to it? I do not think we want to refcount ;-)

> The patch should clean them up.
>
> Alternatively we could finally address the NEEDSWORK comment and
> provide a way to checkout a file without faking an index entry..

Yeah, we should not need index entry, and we should not need the blob object name.

    ... thinks a bit more ...

Having said that, in the longer term, it may be safe to write an actual object out to the object store. The convert-to-working-tree backends currently work only on raw bytes, but it is not inplausible for some new interfaces to want to pass the object name to the backend and tell it either togive raw (converted) bytes back, or to write out the bytes directly to the filesystem, bypassing the main Git process. If we "pretend" in this process, not just we accumulate cruft in-core as Peff points out, we risk giving out an invalid object name to such external mechanisms.

I do not think it is too bad to leave a handful of temporary blobs that are written out by "git checkout -m <other-branch>" in the object store to be GC'ed.