git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Rename conflicts in the index

From
Junio C Hamano <gitster@pobox.com>
Date
Apr 3, 2013, 00:57 UTC
Message-ID
<7vobdw77n5.fsf@alter.siamese.dyndns.org>
In-Reply-To
<7vsj3877u8.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
Show 16 quoted lines
> 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").

Show 25 quoted lines
>  * 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.
Previous: Junio C Hamano
Message 16 of 16 in “Rename conflicts in the index”
  1. Edward ThomsonMar 13, 2013
  2. Junio C HamanoMar 13, 2013
  3. Edward ThomsonMar 13, 2013
  4. Edward ThomsonMar 26, 2013
  5. Junio C HamanoMar 26, 2013
  6. Edward ThomsonMar 26, 2013
  7. Edward ThomsonMar 27, 2013
  8. Junio C HamanoMar 27, 2013
  9. Edward ThomsonMar 27, 2013
  10. Junio C HamanoMar 27, 2013
  11. Edward ThomsonApr 1, 2013
  12. Edward ThomsonApr 2, 2013
  13. Junio C HamanoApr 2, 2013
  14. Edward ThomsonApr 2, 2013
  15. Junio C HamanoApr 3, 2013
  16. Junio C HamanoApr 3, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.