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

Re: [PATCH 0/2] Custom low-level merge driver support.

From
Linus Torvalds <torvalds@linux-foundation.org>
Date
Apr 18, 2007, 18:45 UTC
Message-ID
<alpine.LFD.0.98.0704181136360.2828@woody.linux-foundation.org>
In-Reply-To
<7vslaxhamd.fsf@assigned-by-dhcp.cox.net>
On Wed, 18 Apr 2007, Junio C Hamano wrote:
Show 8 quoted lines
> 
> While I agree with all of the above, I am currently fighting
> with a back-to-drawing-board design problem.
> 
> The series made the low-level 3-way merge machinery
> customizable, which is a progress, but I think merge-recursive
> needs a hook to affect middle-level merge decision, similar to
> what git-merge-one-file does.

Hmm. I think that it's not so much a "hook", as a "recursive merge is a separate merge policy altogether, that just *defaults* to the same final merge policy".

For example, for a three-way merge, it makes sense to do the three-way merge for the "internal" merge too. But it might be that that isn't true for all strategies. For a "blend" merge, blending at the middle level might be the wrong thing to do because it might duplicate the messages, for example.

So maybe the rule could be:
 - for a file with merge strategy "xyzzy", a recursive merge will first 
   look up the merge machinery for "xyzzy-recursive" and if no such merge 
   strategy exists, it will look up merge machinery for "xyzzy".
 - the final merge will always use merge strategy "xyzzy".

So then, assuming I'm right that the "blend" strategy needs soemthing else in the middle (and I'm not sure I'm right at all, this is purely hypothetical ;), you could have something like

	# a recursive merge will always just pick the ORIGINAL
	# version of a file when blending - the blending will
	# be done only on the final merge
	[merge "blend-recursive"]
		name = recursive blend strategy
		driver = cp %O %A
	[merge "blend"]
		name = blend (changelog) strategy
		driver = blend %A %O %B
or something like that?

I _suspect_ that most merge strategies want to use the same strategy for the recursive merge as for the final one, but I haven't really thought it through.

		Linus
Previous: Junio C HamanoNext: Junio C Hamano
Message 12 of 23 in “Custom low-level merge driver support.”
  1. 0/2 Custom low-level merge driver support.Junio C Hamano, Apr 18, 2007
  2. 1/2 Custom low-level merge driver support.Junio C Hamano, Apr 18, 2007
  3. Johannes SixtApr 18, 2007
  4. Johannes SchindelinApr 18, 2007
  5. 2/2 Allow the default low-level merge driver to be configured.Junio C Hamano, Apr 18, 2007
  6. Johannes SchindelinApr 18, 2007
  7. Martin WaitzApr 18, 2007
  8. Junio C HamanoApr 18, 2007
  9. Martin WaitzApr 18, 2007
  10. Linus TorvaldsApr 18, 2007
  11. Junio C HamanoApr 18, 2007
  12. Linus TorvaldsApr 18, 2007
  13. Junio C HamanoApr 18, 2007
  14. Junio C HamanoApr 18, 2007
  15. Linus TorvaldsApr 18, 2007
  16. Linus TorvaldsApr 18, 2007
  17. Junio C HamanoApr 18, 2007
  18. Linus TorvaldsApr 18, 2007
  19. David LangApr 18, 2007
  20. Junio C HamanoApr 18, 2007
  21. Martin WaitzApr 19, 2007
  22. Junio C HamanoApr 19, 2007
  23. Custom low-level merge driver: change the configuration scheme.Junio C Hamano, Apr 18, 2007

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.