Elijah Newren <newren@xxxxxxxxx> writes: > On Thu, Sep 30, 2021 at 1:06 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: >> >> Jeff King <peff@xxxxxxxx> 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.
