Re: Rename conflicts in the index

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Edward Thomson <ethomson@xxxxxxxxxxxxx> writes:

> Junio C Hamano [mailto:gitster@xxxxxxxxx] wrote:
>> Edward Thomson <ethomson@xxxxxxxxxxxxx> 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.
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]