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

Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty base

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Dec 13, 2006, 23:48 UTC
Message-ID
<Pine.LNX.4.63.0612140045430.3635@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To
<b0943d9e0612131401s6cde6d0du5e3c6d2e34bfbbb2@mail.gmail.com>
Hi,
On Wed, 13 Dec 2006, Catalin Marinas wrote:
Show 19 quoted lines
> On 13/12/06, Junio C Hamano <junkio@cox.net> wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > 
> > > Unify the handling for cases C (add/add) and D (modify/modify).
> > >
> > >       On Tue, 12 Dec 2006, Junio C Hamano wrote:
> > >
> > >       > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> > >       >
> > >       > > How about this: if there is an add/add conflict, we treat it
> > >       > > as if there _was_ an empty file, and we let the shiny new
> > >       > > xdl_merge() find the _true_ conflicts, _instead of_ removing
> > >       > > the file from the index, adding both files with different
> > >       > > "~blabla" markers appended to their file names to the working
> > >       > > directory.
> 
> What is this new xdl_merge()? Is it a better replacement for diff3? In 
> this situation diff3 would actually show two confict parts, each of them 
> being the full file, with an empty ancestor.

xdl_merge(), as Git uses it, tries harder to find the true conflicts. So, if the files actually differ in only one line, just this line will be shown as conflict.

There is a flag passed to xdl_merge(), which tells it how hard it should try to make sense of the conflict. We use the "zealous" option, which is most accurate, but also slowest (although I have no numbers).

Show 13 quoted lines
> > This fixes the behaviour in "both branches add the path
> > differently" case.  Previously merge-recursive did not create
> > the working tree file, but now it does just like merge-resolve.
> > 
> > Although I would feel very happy about this change, Catalin
> > might want to be informed about potential interaction this
> > change might have with his commit 8d41555 in StGIT.
> 
> I don't think it affects StGIT. Previously, "git-read-tree -m" left a
> file in the tree in this conflict situation. When I switched to
> git-merge-recursive (to handle renames better), I noticed that the
> file was no longer there and my merge algorithm failed. It now checks
> whether the file is missing and it generates one.
Great!

Ciao, Dscho

Previous: Junio C HamanoNext: Catalin Marinas
Message 32 of 37 in “Make sure the empty tree exists when needed in merge-recursive.”
  1. 1/1 Make sure the empty tree exists when needed in merge-recursive.Shawn O. Pearce, Dec 7, 2006
  2. 1/3 diff_tree_sha1(): avoid rereading trees if possibleJohannes Schindelin, Dec 9, 2006
  3. Junio C HamanoDec 10, 2006
  4. Johannes SchindelinDec 10, 2006
  5. 2/3 merge-recursive: make empty tree a known objectJohannes Schindelin, Dec 9, 2006
  6. Linus TorvaldsDec 10, 2006
  7. Junio C HamanoDec 10, 2006
  8. Linus TorvaldsDec 10, 2006
  9. Junio C HamanoDec 10, 2006
  10. Linus TorvaldsDec 10, 2006
  11. Junio C HamanoDec 10, 2006
  12. Johannes SchindelinDec 10, 2006
  13. 3/3 add test case for recursive mergeJohannes Schindelin, Dec 9, 2006
  14. Johannes SchindelinDec 10, 2006
  15. Junio C HamanoDec 10, 2006
  16. Johannes SchindelinDec 10, 2006
  17. t6024: fix timing problemJohannes Schindelin, Dec 12, 2006
  18. Junio C HamanoDec 12, 2006
  19. Johannes SchindelinDec 12, 2006
  20. merge-recursive: add/add really is modify/modify with an empty baseJohannes Schindelin, Dec 13, 2006
  21. Junio C HamanoDec 13, 2006
  22. StGit repo & gitweb, was Re: [PATCH] merge-recursive: add/add really is modify/modify with an empty baseJohannes Schindelin, Dec 13, 2006
  23. Jakub NarebskiDec 13, 2006
  24. Catalin MarinasDec 13, 2006
  25. Robin RosenbergDec 13, 2006
  26. Johannes SchindelinDec 13, 2006
  27. Jakub NarebskiDec 13, 2006
  28. Petr BaudisDec 19, 2006
  29. Jakub NarebskiDec 19, 2006
  30. Catalin MarinasDec 13, 2006
  31. Junio C HamanoDec 13, 2006
  32. Johannes SchindelinDec 13, 2006
  33. Catalin MarinasDec 14, 2006
  34. Shawn PearceDec 14, 2006
  35. Shawn PearceDec 14, 2006
  36. Johannes SchindelinDec 14, 2006
  37. Catalin MarinasDec 14, 2006

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.