Seth House <seth@xxxxxxxxx> writes: > On Tue, Jan 26, 2021 at 03:32:13PM +0100, Johannes Schindelin wrote: >> So I'd rather see `git mergetool` be turned into a portable C program, or >> alternatively using a built-in helper that _is_ written in C, to perform >> that desired text munging > > I tend to agree. Though my personal preference is Cygwin's (eventual) > approach, I can appreciate the arguments made by the MSYS2 folk. But > setting that aside, IMO, the ideal place to handle this would be the > same place where the conflict markers are written in the first place, > xmerge.c if my limited C literacy is correct. > > I don't see a big distinction between writing a single file with > conflict markers and writing two, diff-able files with each "side" of > the conflict -- they're ultimately two different formats for expressing > the same information. That would give us the portability you described > and the (pretty amazing) performance that merge-file already enjoys. :) > > I'm more than happy with calling merge-file twice for now. A future > C optimisation, perhaps exposed via merge-file as a new (e.g.) > --write-conflict-files flag, would be even more awesome. I am OK with that "two merge-file invocations, one with --ours and then another with --theirs" approach, as I already said in https://lore.kernel.org/git/xmqqh7n9aer5.fsf@xxxxxxxxxxxxxxxxxxxxxx/
