On Fri, Oct 1, 2021 at 10:02 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Elijah Newren <newren@xxxxxxxxx> 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. > Elijah, To Junio's point, I'm also curious about why it's so important to aggressively purge the mechanical merge cache that you want to do it after each diff operation rather than once at the end.
