On Fri, Oct 1, 2021 at 10:39 AM Neeraj Singh <nksingh85@xxxxxxxxx> wrote: > > 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. Performance; I don't want to accumulate hundreds of thousands of loose objects and pay the penalty from them sitting around, especially when I know they're cruft. (My original implementation from a year ago did just clean out once at the end.) For more details, see https://lore.kernel.org/git/CABPp-BGsjq3ts4A6wKLYcopD9rknM+LXXi8qR_SLEpmU+x7KNQ@xxxxxxxxxxxxxx/, starting with "It'd be _much_ slower". Or the email I just sent to Junio.
