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

[Elijah Newren <newren@gmail.com>]

On Fri, Oct 1, 2021 at 10:39 AM Neeraj Singh <nksingh85@gmail.com> wrote:
>
> On Fri, Oct 1, 2021 at 10:02 AM Junio C Hamano <gitster@pobox.com> wrote:
> >
> > Elijah Newren <newren@gmail.com> 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@mail.gmail.com/,
starting with "It'd be _much_ slower".  Or the email I just sent to
Junio.