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

unpack-trees traversing with index quite broken...

From
Junio C Hamano <junio@pobox.com>
Date
Sep 5, 2009, 06:40 UTC
Message-ID
<7vr5ul99o2.fsf@alter.siamese.dyndns.org>
Linus,
I found an issue I do not know how to resolve.
Suppose you try to merge these three trees:
 - Tree #1 (ancestor)
   t   tree, in which there is an entry f that is a blob
   t/f blob
 - Tree #2 (ours)
   t   blob
   t-f blob
 - Tree #3 (theirs)
   t-f blob
The index matches our tree.
The callchain that causes "read-tree -m -u #1 #2 #3" misbehave looks like this.
unpack_trees()
->traverse_trees()
  entry[0] = "t" (tree taken from Tree #1)
  entry[1] = "t" (blob taken from Tree #2)
  entry[2] = nothing
  ->unpack_callback()
    ce = "t" (blob taken from the index)
    ->unpack_nondirectories()
      src[0] = "t" (blob from the index)
      src[1] = conflict (tree taken from Tree #1)
      src[2] = "t" (blob taken from Tree #2)
      src[3] = NULL
    ->call_unpack_fn()
      This callback is perfectly fine.
    /* Now handle any directories.. unpack-trees.c, ll.336- */
    ->traverse_trees_recursive()
      Now we stepped into tree "t".
      ->traverse_trees()
        entry[0] = "f" (blob from "t/" tree in Tree #1)
        entry[1] = nothing (Tree #2 does not have "t/" subtree)
        entry[2] = nothing (Tree #3 does not have "t/" subtree)
        ->unpack_callback()
          ce = "t-f" (blob taken from the index)
          ->compare_entry(ce, entry[])
          <- "t-f" comes anything in "t/" directory, return negative
          Because we are processing "t/something" at this level, and
          "t-f" that should come earlier than any "t/something", we
          assume that there is no matching entries in the trees.
          ->unpack_index_entry(ce = "t-f")
            ->call_unpack_fn()
              This callback is utterly wrong.  "t-f" from the index
              has a matching entry in Tree #2 and Tree #3, but we
              haven't seen them yet!

At first, I thought that we could fudge this particular example by noticing that "t-f" is earlier only because "t-f" sorts before "t/", the path-prefix of the problematic level, and pretend the negative return from compare_entry() as if it was positive (i.e. deferring the processing of the index entry). While this approach lets the problematic level correctly feed only "t/f" to call_unpack_fn() and come back, and the rest may proceed cleanly for this particular case, I do not think it is the right solution.

If Tree #3 had another tree "t/" in it, the situation would look like this instead:

 - Tree #1 (ancestor)
   t   tree, in which there is an entry f that is a blob
   t/f blob
 - Tree #2 (ours, matches the index)
   t   blob
   t-f blob
 - Tree #3 (theirs)
   t-f blob
   t   tree, in which there is an entry f that is a blob    

Since traverse_trees() wants to walk the trees in parallel, never seeking back, I do not think it would feed t-f from Tree #2 and Tree #3 to the unpack_callback() sanely. Worse yet, the logic to walk the index in parallel while this is happening (i.e. "Are we supposed to look at the index too?" part) does not want to seek o->pos pointer back either, so I am stuck X-<...

Message 1 of 1 in “unpack-trees traversing with index quite broken...”
  1. Junio C HamanoSep 5, 2009

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.