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.
