Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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.)
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
