Subject: Re: What's cooking in git.git (Sep 2021, #08; Mon, 27)

From: Junio C Hamano <[email-masked]>
Date: Fri, 01 Oct 2021 10:02:41 -0700

Elijah Newren <[email-masked]> writes:

> Said another way, I don't think anything should be writing a critical
> file that needs to be durable when we're in the middle of a
> "read-only" process like git-log.  The only things written should be
> temporary stuff, like the automatic remerge calculation from
> merge-ort, the textconv cache optimization stuff, or perhaps future
> gitattributes transformation caching.  All that stuff can safely be
> blown away at the completion of each merge.

The textconv cache can be populated/written during "git log -p" into
the object store to persist.  With or without "--remerge-diff", we
can make design decision to either 

 - use temporary object store to discard everything we create at the
   end in one-go, or

 - write them into the object store to let later gc to handle the
   crufts.

The former will disable persistent write access to the cache.  It
still allows accesses the cached data during the same process,
though.  We so far deemed that textconv cache, when the user enables
it, is valuable enough to make persistent.  Perhaps remerge-diff's
tentative merge result may fall into the same category?  Some folks
may want to cache, others may not.

If we were to use the same notes-cache mechanism, we record the tree
object (perhaps the object name) as the cached value for the merge
commit in question.  Hopefully most of the merges are clean merges,
and "caching" the results of the recreation of the merge would cost
almost nothing.  We need objects to record the fact that "this merge
has cached result" in the notes-cache, but the tree object that
represents the cached result is already in the history the merge
belongs to.