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

Re: Strange merge failure (would be overwritten by merge / cannot merge)

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 6, 2009, 20:36 UTC
Message-ID
<7vws4bzu7w.fsf@alter.siamese.dyndns.org>
In-Reply-To
<alpine.LFD.2.01.0909061248470.8946@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
Show 20 quoted lines
> On Sun, 6 Sep 2009, Junio C Hamano wrote:
>...
>>  * traverse_trees() takes a callback from the caller in info->fn().  It
>>    feeds the callback the entries with the same name most of the time, but
>>    that is not a guarantee, and the bug we are seeing is coming from a
>>    caller, unpack_trees_callback(), assuming it.
>
> This is the level I'm looking at. In fact, I'm going to cheat. I'm not 
> going to do it when we call info->fn(), I'm going to do it _before_ the 
> call, and have a special "find conflicts" phase inside traverse_trees() 
> itself.
>
> That way, any traverse_trees() user will see the conflicts exactly like 
> they used to, because I'm just going to add a special "find conflicts" 
> phase there that does the right thing. It's a hack, but it's a "useful" 
> hack, and it at least avoids being the current "it can't work for the 
> special case" thing.
> ...
> I think I have a good solution, give me half an hour to actually get it to 
> work.
Thanks.

The reason I brought up adding the "candidate for the earliest name" interface to the function was to avoid a case where the index has

    blob "t"
    blob "t-f"
and all the trees being merged have
    blob "t-f"
    tree "t"

in which case the "Are we supposed to look at the index too?" logic in unpack_callback() may not catch the "t-f" entry from the index when the first callback from traverse_trees() feeds it "t-f". It would notice that the entry at o->pos is "t". When that happens, I did not think of a clean way to avoid the codepath from emitting "t" as "only exists in the index". With the "candidate" addition, traverse_trees() could say "You asked me that I may have to return 't' to you, and here are the entries from all the trees." before giving "t-f" back.

Other than that, I think find_conflicts() phase in the traverse_trees() makes sense.

Previous: Linus TorvaldsNext: Linus Torvalds
Message 10 of 16 in “Strange merge failure (would be overwritten by merge / cannot merge)”
  1. Christoph HaasSep 4, 2009
  2. David AguilarSep 4, 2009
  3. Christoph HaasSep 5, 2009
  4. Junio C HamanoSep 5, 2009
  5. Junio C HamanoSep 6, 2009
  6. Junio C HamanoSep 6, 2009
  7. Linus TorvaldsSep 6, 2009
  8. Junio C HamanoSep 6, 2009
  9. Linus TorvaldsSep 6, 2009
  10. Junio C HamanoSep 6, 2009
  11. Linus TorvaldsSep 6, 2009
  12. Linus TorvaldsSep 6, 2009
  13. Junio C HamanoSep 6, 2009
  14. Linus TorvaldsSep 6, 2009
  15. Linus TorvaldsSep 6, 2009
  16. Junio C HamanoSep 6, 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.