Re: automerge implementation ideas for Windows

[Junio C Hamano <gitster@pobox.com>]

Seth House <seth@eseth.com> writes:

> On Thu, Jan 21, 2021 at 02:50:12PM -0800, Junio C Hamano wrote:
>> I'd rather not to see us do "text processing" in shell
>
> Agreed. What are your thoughts on the #2 approach?
>
> I noticed the comment in `git/xdiff-interface.h` about xdiff's gigabyte
> limit so I created a 973 MB text file with a conflict and ran #2 through
> a few mergetools to see how it went. I put /usr/bin/time in front of the
> two `git merge-file` invocations. I know one person's machine is not
> a benchmark but perhaps it's a discussion point?
>
> Each `git merge-file` call took ~11 seconds on my middle-tier laptop and
> did not use enough RAM to hit swap.
>
> Writing the near-gigabyte LOCAL, BASE, REMOTE, & BACKUP files went
> pretty quick. The mergetools themselves had mixed results:
>
> - vimdiff took several minutes (and a lot of swap) to open all four
>   files but did eventually work.
> - tkdiff crashed.
> - Meld spun for ~10 minutes and never opened.
>
> My takeaway: when trying to use a mergetool on a very large file, the
> two `git merge-file` invocations are not likely to be where the
> performance concern is. #2 is my preferred approach so far.

Yeah, I am no expert about Windows, but at least I know how well
"git merge-file" should work _anywhere_ (as opposed to "read -r"
plus shell loop that I would not trust on a platform where even
basic things like "sed" behaves differently from what we expect
X-<), so from that point of view, it is vastly more preferrable,
if the choices were only between #1 and #2.