Re: [PATCH v3 00/32] object-store: lookup_commit

From: Brandon Williams <bmwill@google.com>
Date: Jun 29, 2018, 22:20 UTC
Message-ID: <20180629222004.GA197765@google.com>
In-Reply-To: <xmqqvaa1tme8.fsf@gitster-ct.c.googlers.com>

On 06/29, Junio C Hamano wrote:

Show 29 quoted lines

> Stefan Beller <sbeller@google.com> writes:
> 
> > On Fri, Jun 29, 2018 at 11:03 AM Junio C Hamano <gitster@pobox.com> wrote:
> >>
> >> Junio C Hamano <gitster@pobox.com> writes:
> >>
> >> > One technique these (not just this) recent efforts seem to be
> >> > forgetting is to introduce "new" names that take a_repo and then
> >> > make the existing one a thin wrapper that calls the new one with
> >> > &the_repo as the argument.
> >
> > So you'd rather want to see it less invasive done similar to
> > NO_THE_INDEX_COMPATIBILITY_MACROS ? Someone (jrnieder?)
> > called that a failed experiment, as now we need to carry that baggage
> > for quite some time and never cleaned up the started migration;
> > only recently Duy started to kill off the_index, which would finish
> > that migration?
> 
> I do not think it was a failed experiment at all.  In fact, most of
> our code is still happy with the single in-core instance of
> the_index, and I think it is a mistake to trying to use the variant
> that take an istate instance as parameter just for the sake of it.
> 
> IOW, if there is a good concrete reason why it helps to teach the
> set of functions involved in a callchain to operate on an in-core
> instance of the index_state, passing an istate through the callchain
> is a very welcome change.  If you do not do so, and then just
> replace $foo_cache(...) with $foo_index(&the_index, ...), that is an
> irritating and useless code churn that harms other topics in flight.

I 100% think that we need to continue these refactorings with both the object store as well as with the_index (removing the index macros and removing the dependency on global state). The whole compat macros most definitely was a failed experiment as we still haven't rid the code base of them yet. Having two APIs which can be used interchangeably from different pieces of library code which have very different semantics is _very_ difficult for contributors to reason about and work around. Especially when one API relies on implied global state while the other does not. (If global state isn't involved, as in the char[20] -> OID work, then having two APIs is 'ok' so long as you're working towards converging to one API).

Having clean APIs makes it incredible easy to reason about sections of code, reason about multi-threading, and implement newer features in a sane manner (talking about submodules here). I implemented submodule support for grep twice, once using a multi-process paradigm because we could not have two repositories open in a single process and then an in-process one once a minimum viable solution for opening multiple repositories in a single process was created. Being able to open up a submodule repository in-process made things infinitely simpler to reason about as well as made it much easier to handle errors. This work needs to continue if we want to improve the submodule experience in git.

Yes this might mean there are a few more conflicts when merging a series (because of the scope of these refactorings) but it is well worth it given what the end-state will look like.

-- 
Brandon Williams