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

Re: [PATCHv2 2/2] merge-recursive: D/F conflicts where was_a_dir/file -> was_a_dir

From
Junio C Hamano <gitster@pobox.com>
Date
Sep 10, 2010, 00:26 UTC
Message-ID
<7vhbhyjvf2.fsf@alter.siamese.dyndns.org>
In-Reply-To
<1283928041-9882-3-git-send-email-newren@gmail.com>
Elijah Newren <newren@gmail.com> writes:
Show 5 quoted lines
> ... git can't know that there's a conflict
> until after it's tried resolving paths involving newsub/newfile to see if
> they are still in the way at the end (and if newsub/newfile is not in the
> way at the end, there should be no conflict at all, which did not hold with
> git previously).

I'll queue this patch to 'pu', but anybody who wrote the above to correctly arriave at the crux of the issue in his analysis would know that this is another band-aid on top of band-aid. The approach merge-recursive takes to first grab the set of directories and files fundamentally is wrong---it should be resolving the paths in-core first and then look at the result to ignore a directory that has become empty.

Previous: Elijah NewrenNext: Elijah Newren
Message 4 of 5 in “[PATCHv2 0/2] Fix resolvable rename + D/F conflict testcases”
  1. Elijah NewrenSep 8, 2010
  2. 1/2 t3509: Add rename + D/F conflict testcase that recursive strategy failsElijah Newren, Sep 8, 2010
  3. 2/2 merge-recursive: D/F conflicts where was_a_dir/file -> was_a_dirElijah Newren, Sep 8, 2010
  4. Junio C HamanoSep 10, 2010
  5. Elijah NewrenSep 8, 2010

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.