Re: automerge implementation ideas for Windows

Seth House [off-list ref] writes:

One other point of discussion: I would like to change the name of this
feature. "Automerge" is a bit of an overloaded term and, IMO, doesn't
describe this feature very well. Several of the GUI diff programs have
a feature that they call "automerge" or "auto merge", and there's a flag
for Meld already in Git called "mergetool.meld.useAutoMerge" which could
cause confusion.

Instead, I'd like to propose "mergetool.hideResolved" or the more
verbose "mergetool.hideResolvedConflicts" as the name. We're not really
merging anything (Git aleady did that before the mergetool is invoked),
but rather we're just not showing any conflicts that Git was already
able to resolve.

I have no objetion.  I didn't think 'automerge' was bad, but it
probably is too broad a word as you discuss in the above.

"hide resolved" sounds like the name that describes what it does
quite well.

#1: Use POSIX read and a while loop to emulate an awk-like approach:

I'd rather not to see us do "text processing" in shell, especially
with "read -r".  I just do not trust it (even with the "-r" option).

Having said that, I am not familiar enough to the Windows
environment to know what is trustworthy and what is not (apparently,
things like "sed" that I would intuitively place as much trust as
anything else is giving us so much trouble out of box), so I'll
shut up and listen to others.

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.