Junio C Hamano <gits...@pobox.com> writes:

> If I were solving the issue, I would probably proceed like this:
>  * Start from a rough sketch of what extra information I would want
>    to store in the new index extension section.
>  * Teach read-cache.c to read from the new extension and keep it in
>    an in-core data structure, and read from the in-core data
>    structure and seriealize it to write to the extension section.
>  * Perhaps enhance "update-index" so that it can read textual
>    representation of the contents of the new extension section, turn
>    it into the in-core representation, so that it can write it out
>    to the index file, as a debugging/development aid.
>  * Teach read-cache.c to read from the new extension and keep it in
>    an in-core data structure.

Sorry, this is a dup of the second one.  Please ignore.

Also, all "you" in this section should read "I" (because this is a
description of "If I were solving it").

>  * Teach wt-status.c to read from that in-core data structure and
>    improve the presentation of the cases I care about using that
>    information.  Use the "update-index" development aid to prepare
>    various cases you care about.
>     - If the kind of information that is stored in the new extension
>       turns out to be insufficient, go back to the beginning and
>       iterate.
>     - If the use the in-core data structure here turns out to be
>       awkward, go back one step and iterate.
>     - As I cover one more case, I would add a test to the test suite
>       so that we would know what cases are covered and what the
>       expected end-user presentation should be.
>  * Once the result of the above covers all the cases I care about,
>    then update merge-recursive.c to prepare the in-core data
>    structure to be written out as the extension section.
> As I iterate, the rough sketch will hopefully cover all the cases I
> care about and I'll be ready to write them down as an update to the
> document somewhere in Documentation/technical/api-*.
> Thanks.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to