Re: [PATCH] bisect: fix replay of CRLF logs

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: May 9, 2020, 22:17 UTC
Message-ID: <20200509221730.GG7234@camp.crustytoothpaste.net>
In-Reply-To: <20200508171232.GA637136@coredump.intra.peff.net>

On 2020-05-08 at 17:12:32, Jeff King wrote:

Show 17 quoted lines

> On Fri, May 08, 2020 at 09:28:56AM -0700, Junio C Hamano wrote:
> 
> > -- >8 --
> > From: Christopher Warrington <chwarr@microsoft.com>
> > Subject: [PATCH] bisect: allow CRLF line endings in "git bisect replay" input
> > 
> > We advertise that the bisect log can be corrected in your editor
> > before being fed to "git bisect replay", but some editors may
> > turn the line endings to CRLF.
> > 
> > Update the parser of the input lines so that the CR at the end of
> > the line gets ignored.
> 
> I'm a little surprised that bash "read" on Windows doesn't eat CRLFs
> already. But I often find myself confused by line ending decisions in
> general, as well as the difference between cygwin versus msys versus
> pure windows binaries, etc.

I was surprised by that as well, but I believe at least the bash in Git for Windows is LF-only and doesn't do anything special with CR. In fact, ISTR it chokes on shell scripts with CR line endings just as every shell on Unix does. The commits from Dscho and Stolee to our current .gitattributes file explain the situation quite well.

Cygwin allows configurable behavior for line endings, but I don't know whether any configuration it allows handles CR in the shell. I'm sure Cygwin will do the right thing with LF only lines regardless, so it's probably safe to just assume LF-only behavior in the shell.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204