Re: Rename conflicts in the index

Junio C Hamano [off-list ref] 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.