Re: Re* [PATCH v2] fixup! mergetool: add automerge configuration

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jan 26, 2021, 14:32 UTC
Message-ID: <nycvar.QRO.7.76.6.2101261522200.57@tvgsbejvaqbjf.bet>
In-Reply-To: <YAte7ixZYdz1AOMX@camp.crustytoothpaste.net>

Hi brian,

On Fri, 22 Jan 2021, brian m. carlson wrote:

Show 33 quoted lines

> On 2021-01-22 at 16:29:46, Johannes Schindelin wrote:
> >
> > On Fri, 22 Jan 2021, brian m. carlson wrote:
> >
> > > On 2021-01-16 at 04:24:54, Seth House wrote:
> > > > The autocrlf test is breaking because the sed that ships with some mingw
> > > > versions (and also some minsys and cygwin versions) will *automatically*
> > > > remove carriage returns:
> > > >
> > > > $ printf 'foo\r\nbar\r\n' | sed -e '/bar/d' | cat -A
> > > > foo$
> > > >
> > > > $ printf 'foo\r\nbar\r\n' | sed -b -e '/bar/d' | cat -A
> > > > foo^M$
> > > >
> > > > (Note: the -b flag above is just for comparison. We can't use it here.
> > > > It's not in POSIX and is not present in sed for busybox or OSX.)
> > >
> > > Can you report this as a bug?  This behavior isn't compliant with POSIX
> > > and it makes it really hard for folks to write portable code if these
> > > versions implement POSIX utilities in a nonstandard way.  As a
> > > non-Windows user, I have no hope of writing code that works on Windows
> > > if we can't rely on our standard utilities working properly.
> >
> > I fear that the Windows-based tools do the correct thing, though: they are
> > meant to process _text_, and newlines are supposed to be
> > platform-dependent in text.
>
> Ah, but POSIX gives a very specific meaning to "newline", and it refers
> to a single byte.  If you want tools that process CRLF line endings like
> that, then that should be opt-in as either different tools or additional
> options, not the default behavior of a POSIX tool.  This behavior is not
> conforming to POSIX and it is therefore a defect.

If we needed another reminder that

	we never say "It's in POSIX; we'll happily ignore your needs
	should your system not conform to it."

(https://github.com/git/git/blob/v2.30.0/Documentation/CodingGuidelines), then we have it right here ;-)

Show 6 quoted lines

> > From that perspective, it sounds to me as if we're trying to ask `sed` to
> > do something it was not designed to do: binary editing.
>
> Most Windows tools are perfectly capable of handling LF line endings.
> Even the famously incapable Notepad can now handle LF without CR.  With
> the advent of WSL, handling LF line endings is now pretty much required.

I have two comments on that:

1. We could spend a splendid time questioning MSYS2's (and before that,
   MSys') choices regarding newlines, but I think we can spend that time a
   lot better.

2. Newer software _seems_ to handle LF line endings just fine. And the
   `sed` invocation you mentioned above does so: it groks input delimited
   by Line Feed as newline characters. That does not mean that its output
   is LF-only by default. I seem to remember that recent Visual Studio
   versions did something similar: happily read an LF-only `.xml` file,
   but then write out a modified version using CR/LF.

Would I wish that Windows used LF-only instead of CR/LF, just like macOS switched away from CR-only to LF-only after MacOS 9? Sure I do. It would remove quite a few obstacles in my daily work. Can I do anything about it? No.

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 instead of losing the battle to the challenge of cross-platform, advanced text processing in pure shell script.

Ciao, Dscho