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