Re: [PATCH 5/7] tmp-objdir: new API for creating and removing primary object dirs

[Junio C Hamano <gitster@pobox.com>]

Elijah Newren <newren@gmail.com> writes:

> On Thu, Sep 30, 2021 at 1:06 PM Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Jeff King <peff@peff.net> writes:
>>
>> >   - is it possible for the merge code to ever write an object? I kind of
>> >     wonder if we'd ever do any cache-able transformations as part of a
>> >     content-level merge. I don't think we do now, though.
>>
>> How is virtual merge base, result of an inner merge that recursively
>> merging two merge bases, fed to an outer merge as the ancestor?
>> Isn't it written as a tree object by the inner merge as a tree with
>> full of blob objects, so the outer merge does not have to treat a
>> merge base tree that is virtual any specially from a sole merge
>> base?
>
> Yes.  And that's not unique to the inner merges; it also writes new
> blob and tree objects for the outer merge, and then passes the
> resulting toplevel tree id out as the result.

I think Peff's question was "other than what is contained in the
merge result, are there objects we create during the merge process
that we may want to keep?"  And my inner merge example was objects
that do not appear in the merge result, but they are discardable,
so it wasn't a good example.

A tentative merge to recreate what the manual resolver would have
seen while showing remerge-diff needs to be recorded somewhere
before the diff gets shown, but after showing the diff, we can lose
them unless we need them for some other reason (e.g. they already
existed, another process happened to have created the same blob
while we are running remerge-diff, etc.).  So in that sense, the
objects that represent the result of the outermost merge is also
discardable.

The question is if there are other things similar to the textconv
cache, where we need to create during the operation and may keep the
result for later use.  The closest thing I can think of is the
rename cache we've talked about from time to time without actually
adding one ;-).

I guess using cached textconv result, without putting newly
discovered textconv result back to the cache, would be the best we
can do?

The blobs (hence their textconv results) involved in showing a merge
M with --remerge-diff are the ones in the trees of M^@ (all parents)
and $(git merge-base $(git rev-parse M^@)), and they may have been
created when running "git show" on or when letting "git log -p"
pass, these commits, so it is not like we are disabling the cache
entirely, and allowing read-only access may still have value.

Thanks.