Re: Rename conflicts in the index

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 3, 2013, 00:53 UTC
Message-ID: <7vsj3877u8.fsf@alter.siamese.dyndns.org>
In-Reply-To: <7vr4isaath.fsf@alter.siamese.dyndns.org>

Edward Thomson <ethomson@microsoft.com> writes:

Show 14 quoted lines

> Junio C Hamano [mailto:gitster@pobox.com] wrote:
>> Edward Thomson <ethomson@microsoft.com> writes:
>> > Junio, did you have additional thoughts on this?
>> 
>> Not at this moment.
>> 
>> I think we have covered the principles (do not unnecessarily duplicate
>> information, do not break existing implementations unnecessarily, etc.) already,
>> and we know how we want to record "one side renamed A to B, the other side
>> renamed A to C" case, but I do not think the discussion covered all cases yet.
>
> Sorry, I'm not sure what you're asking for - would you just like some more
> examples of what this looks like with aforementioned exotic conflict types?
> Or are you looking for something more strict - BNF format, for example?

Ehh, I wasn't asking for anything ;-)

You asked if I had any additional thoughts, I answered there is nothing at this moment based on what I saw so far. It is not my immediate itch to update the index with more rename information, but it is yours, so I would imagine you would know what cases you would want to improve the end user experience better than I do ;-).

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.

 * 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.