Re: [PATCH 2/5] First step, making setup (somewhat) reentrant

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Which brings me to a more fundamental question: what do you need reentrant 
> setup_directory() for?  If it is just to allow multiple calls to that 
> function for the _same_ repository, I say clean up your code.

IIRC, he is writing a set-of-repositories browser.

But I think the right approach of cleaning up is to design a
layer of containers like we did for "the_index" libification
[*1*].  We would probably want:

 * a container that abstracts accesses to a single repository
   that includes:

    - set of refs;

    - object database and object hash (because different
      repositories can have different notion of who is parent of
      whom);

 * a container that abstracts accesses to a state of the index
   (we already have this -- the_index).

 * a container that abstracts a manipulation state in a single
   repository, that points at the first one but somehow knows
   what in-core objects are rewritten during its operation
   (e.g. history simplification rewrites parents list in in-core
   commit objects).

and a relatively low impact approach to transition to such a
scheme would be to use "the_index" libification as the model.
I.e. make the real API to take an explicit container as one of
their parameter, but define the default container to work on for
each level, and express the existing API in terms of the updated
API that works on the default container.


[Reference]

  228e94f93570b580da388069900c56b813c91953 (Move index-related
  variables into a structure.)

  4aab5b46f44a7ba860e07a52be506b7b57b2bd5f (Make read-cache.c
  "the_index" free.)