Edward Thomson <[email protected]> writes:
> Junio C Hamano [mailto:[email protected]] wrote:
>> Edward Thomson <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
