threads / discuss / 53642

osx autocrlf sanity?

Subject: osx autocrlf sanity?

## tl;dr

11 messages between Jun 9, 2020 and Jun 10, 2020.

replies: 10people: 5as markdown or json

Martin Langhoff· Jun 9, 2020, 19:52 UTC · lore

Hi git list,

long time no see! I am here to ask for a sanity check. I'm on OSX. Checking out a repository that has an un-controlled mix of line endings. Mostly linux-style, but some Windows CRLF endings.

A few tests.
 - I set core.autocrlf=input globally --> a fresh clone doesn't have a
clean status files look modified right after a clone)
 - set core.autocrlf=false globally --> a fresh clone doesn't have a
clean status
 - set core.autocrlf=true globally --> a fresh clone doesn't have a clean status

This is git v2.23.0 from Homebrew.

Am I doing something wrong? Can git work sanely on a mixed endings repo without having to fix the world first?

... I do strive to fix the world (and this small repository), as we all do, but it should not be a preconditions before git behaves sanely.

cheers,

martin

-- 
 martin.langhoff@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted        ~  http://github.com/martin-langhoff
   by shiny stuff

brian m. carlson· Jun 9, 2020, 23:13 UTC · re: Martin Langhoff · lore

Re: osx autocrlf sanity?

On 2020-06-09 at 19:52:42, Martin Langhoff wrote:

Show 21 quoted lines

> Hi git list,
> 
> long time no see! I am here to ask for a sanity check. I'm on OSX.
> Checking out a repository that has an un-controlled mix of line
> endings. Mostly linux-style, but some Windows CRLF endings.
> 
> A few tests.
>  - I set core.autocrlf=input globally --> a fresh clone doesn't have a
> clean status files look modified right after a clone)
>  - set core.autocrlf=false globally --> a fresh clone doesn't have a
> clean status
>  - set core.autocrlf=true globally --> a fresh clone doesn't have a clean status
> 
> This is git v2.23.0 from Homebrew.
> 
> Am I doing something wrong? Can git work sanely on a mixed endings
> repo without having to fix the world first?
> 
> ... I do strive to fix the world (and this small repository), as we
> all do, but it should not be a preconditions before git behaves
> sanely.

Does this repository have a .gitattributes file and if so, is there any correlation between the patterns in that file and the modified files?

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

Martin Langhoff· Jun 9, 2020, 23:31 UTC · re: brian m. carlson · lore

Re: osx autocrlf sanity?

Hi Brian,

good question! There is a .gitattributes file, all the files affected have these attributes

*.py     text diff=python

regards,

martin

On Tue, Jun 9, 2020 at 7:14 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 29 quoted lines

>
> On 2020-06-09 at 19:52:42, Martin Langhoff wrote:
> > Hi git list,
> >
> > long time no see! I am here to ask for a sanity check. I'm on OSX.
> > Checking out a repository that has an un-controlled mix of line
> > endings. Mostly linux-style, but some Windows CRLF endings.
> >
> > A few tests.
> >  - I set core.autocrlf=input globally --> a fresh clone doesn't have a
> > clean status files look modified right after a clone)
> >  - set core.autocrlf=false globally --> a fresh clone doesn't have a
> > clean status
> >  - set core.autocrlf=true globally --> a fresh clone doesn't have a clean status
> >
> > This is git v2.23.0 from Homebrew.
> >
> > Am I doing something wrong? Can git work sanely on a mixed endings
> > repo without having to fix the world first?
> >
> > ... I do strive to fix the world (and this small repository), as we
> > all do, but it should not be a preconditions before git behaves
> > sanely.
>
> Does this repository have a .gitattributes file and if so, is there any
> correlation between the patterns in that file and the modified files?
> --
> brian m. carlson: Houston, Texas, US
> OpenPGP: https://keybase.io/bk2204

-- 
 martin.langhoff@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted        ~  http://github.com/martin-langhoff
   by shiny stuff

brian m. carlson· Jun 10, 2020, 00:03 UTC · re: Martin Langhoff · lore

Re: osx autocrlf sanity?

On 2020-06-09 at 23:31:23, Martin Langhoff wrote:

Show 6 quoted lines

> Hi Brian,
> 
> good question! There is a .gitattributes file, all the files affected
> have these attributes
> 
> *.py     text diff=python

By default, Git will check out files with the text attribute with the native line ending, and it will check them in with LF endings. That can be controlled by core.eol and core.autocrlf.

If the file in the repository (as shown by a "git show HEAD:filename") has CRLF endings (usually less shows this as "^M"), then the user has done something naughty by overriding the .gitattributes file with local overrides and checking data in nevertheless. If so, you'll have problems on a Unix system pretty much regardless, unless you set core.eol to "crlf", in which case you'll get all CRLF files.

It may be instructive to run "git diff --ws-error-highlight=all" to see what the changes are in the working tree compared to what's checked in. I suspect it will probably be line endings only.

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

Martin Langhoff· Jun 10, 2020, 13:55 UTC · re: brian m. carlson · lore

Re: osx autocrlf sanity?

On Tue, Jun 9, 2020 at 8:04 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 9 quoted lines

> On 2020-06-09 at 23:31:23, Martin Langhoff wrote:
> > good question! There is a .gitattributes file, all the files affected
> > have these attributes
> >
> > *.py     text diff=python
>
> By default, Git will check out files with the text attribute with the
> native line ending, and it will check them in with LF endings.  That can
> be controlled by core.eol and core.autocrlf

Why is core.autocrlf false not working for me?

I want to work on a repo that has a mix of newlines. I'd like git to completely ignore them. Treat all files as a bag'o'bytes.

Assume I am running git rebase over commits that have .gitattributes, so I can't "just remove it".

regards,

-- 
 martin.langhoff@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted        ~  http://github.com/martin-langhoff
   by shiny stuff

Randall S. Becker· Jun 10, 2020, 13:59 UTC · re: Martin Langhoff · lore

RE: osx autocrlf sanity?

On June 10, 2020 9:55 AM, Martin Langhoff wrote:

Show 23 quoted lines

> To: brian m. carlson <sandals@crustytoothpaste.net>; Martin Langhoff
> <martin.langhoff@gmail.com>; Git Mailing List <git@vger.kernel.org>
> Subject: Re: osx autocrlf sanity?
> 
> On Tue, Jun 9, 2020 at 8:04 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> > On 2020-06-09 at 23:31:23, Martin Langhoff wrote:
> > > good question! There is a .gitattributes file, all the files
> > > affected have these attributes
> > >
> > > *.py     text diff=python
> >
> > By default, Git will check out files with the text attribute with the
> > native line ending, and it will check them in with LF endings.  That
> > can be controlled by core.eol and core.autocrlf
> 
> Why is core.autocrlf false not working for me?
> 
> I want to work on a repo that has a mix of newlines. I'd like git to completely
> ignore them. Treat all files as a bag'o'bytes.
> 
> Assume I am running git rebase over commits that have .gitattributes, so I
> can't "just remove it".

We use core.autocrlf=input on all our platforms for source files, including OSX.

Does that work for you?

Regards, Randall

-- Brief whoami:
 NonStop developer since approximately 211288444200000000
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

Martin Langhoff· Jun 10, 2020, 14:19 UTC · re: Randall S. Becker · lore

Re: osx autocrlf sanity?

From my original post -

A few tests.
 - I set core.autocrlf=input globally --> a fresh clone doesn't have a
clean status files look modified right after a clone)
 - set core.autocrlf=false globally --> a fresh clone doesn't have a
clean status
 - set core.autocrlf=true globally --> a fresh clone doesn't have a clean status

... I was an early contributor to git, so I am hopefully not too naive about the basics. Of course, I sometimes make a boneheaded mistake.

cheers,

On Wed, Jun 10, 2020 at 9:59 AM Randall S. Becker <rsbecker@nexbridge.com> wrote:

Show 40 quoted lines

>
> On June 10, 2020 9:55 AM, Martin Langhoff wrote:
> > To: brian m. carlson <sandals@crustytoothpaste.net>; Martin Langhoff
> > <martin.langhoff@gmail.com>; Git Mailing List <git@vger.kernel.org>
> > Subject: Re: osx autocrlf sanity?
> >
> > On Tue, Jun 9, 2020 at 8:04 PM brian m. carlson
> > <sandals@crustytoothpaste.net> wrote:
> > > On 2020-06-09 at 23:31:23, Martin Langhoff wrote:
> > > > good question! There is a .gitattributes file, all the files
> > > > affected have these attributes
> > > >
> > > > *.py     text diff=python
> > >
> > > By default, Git will check out files with the text attribute with the
> > > native line ending, and it will check them in with LF endings.  That
> > > can be controlled by core.eol and core.autocrlf
> >
> > Why is core.autocrlf false not working for me?
> >
> > I want to work on a repo that has a mix of newlines. I'd like git to completely
> > ignore them. Treat all files as a bag'o'bytes.
> >
> > Assume I am running git rebase over commits that have .gitattributes, so I
> > can't "just remove it".
>
> We use core.autocrlf=input on all our platforms for source files, including OSX.
>
> Does that work for you?
>
> Regards,
> Randall
>
> -- Brief whoami:
>  NonStop developer since approximately 211288444200000000
>  UNIX developer since approximately 421664400
> -- In my real life, I talk too much.
>
>
>

-- 
 martin.langhoff@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted        ~  http://github.com/martin-langhoff
   by shiny stuff

brian m. carlson· Jun 10, 2020, 23:53 UTC · re: Martin Langhoff · lore

Re: osx autocrlf sanity?

On 2020-06-10 at 13:55:12, Martin Langhoff wrote:

Show 13 quoted lines

> On Tue, Jun 9, 2020 at 8:04 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> > On 2020-06-09 at 23:31:23, Martin Langhoff wrote:
> > > good question! There is a .gitattributes file, all the files affected
> > > have these attributes
> > >
> > > *.py     text diff=python
> >
> > By default, Git will check out files with the text attribute with the
> > native line ending, and it will check them in with LF endings.  That can
> > be controlled by core.eol and core.autocrlf
> 
> Why is core.autocrlf false not working for me?

core.autocrlf to false means that it is disabled and has no effect. core.eol defaults to "lf" on Unix systems and "crlf" on Windows, and is used even when core.autocrlf is disabled.

> I want to work on a repo that has a mix of newlines. I'd like git to
> completely ignore them. Treat all files as a bag'o'bytes.

Then you need to use plumbing commands like git cat-file. You could also write a .git/info/attributes file that contains the following:

    *.py !text

or

    * !text

which will override the file in the repository.

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

Torsten Bögershausen· Jun 10, 2020, 14:34 UTC · re: Martin Langhoff · lore

Re: osx autocrlf sanity?

On Tue, Jun 09, 2020 at 07:31:23PM -0400, Martin Langhoff wrote:

Show 6 quoted lines

> Hi Brian,
>
> good question! There is a .gitattributes file, all the files affected
> have these attributes
>
> *.py     text diff=python

That is the important information, that we need.
Since there is a .gitattributes file, (wich is good),
you can forget about core.autocrlf (at least for all python files).
(That should be clear from the documentation of Git,
 but it could be, that we can make things more clear).

There is only one way out of this dilemma: renormalize the line endings in the repo (and live a happier life ;-)

https://git-scm.com/docs/git-add

Sorry to say it this short, this has nothing to do with OSX, it is the repo itself, which needs the renormalization.

Show 45 quoted lines

>
> regards,
>
>
> martin
>
> On Tue, Jun 9, 2020 at 7:14 PM brian m. carlson
> <sandals@crustytoothpaste.net> wrote:
> >
> > On 2020-06-09 at 19:52:42, Martin Langhoff wrote:
> > > Hi git list,
> > >
> > > long time no see! I am here to ask for a sanity check. I'm on OSX.
> > > Checking out a repository that has an un-controlled mix of line
> > > endings. Mostly linux-style, but some Windows CRLF endings.
> > >
> > > A few tests.
> > >  - I set core.autocrlf=input globally --> a fresh clone doesn't have a
> > > clean status files look modified right after a clone)
> > >  - set core.autocrlf=false globally --> a fresh clone doesn't have a
> > > clean status
> > >  - set core.autocrlf=true globally --> a fresh clone doesn't have a clean status
> > >
> > > This is git v2.23.0 from Homebrew.
> > >
> > > Am I doing something wrong? Can git work sanely on a mixed endings
> > > repo without having to fix the world first?
> > >
> > > ... I do strive to fix the world (and this small repository), as we
> > > all do, but it should not be a preconditions before git behaves
> > > sanely.
> >
> > Does this repository have a .gitattributes file and if so, is there any
> > correlation between the patterns in that file and the modified files?
> > --
> > brian m. carlson: Houston, Texas, US
> > OpenPGP: https://keybase.io/bk2204
>
>
>
> --
>  martin.langhoff@gmail.com
>  - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
>  - don't be distracted        ~  http://github.com/martin-langhoff
>    by shiny stuff

Martin Langhoff· Jun 10, 2020, 14:51 UTC · re: Torsten Bögershausen · lore

Re: osx autocrlf sanity?

On Wed, Jun 10, 2020 at 10:34 AM Torsten Bögershausen <tboegi@web.de> wrote:

> There is only one way out of this dilemma:
> renormalize the line endings in the repo (and live a happier life ;-)

that's not a useful answer for me.

git used to be extremely good treating all files as a bag of bytes, not trying to interpret them. How can I get that?

regards,

-- 
 martin.langhoff@gmail.com
 - ask interesting questions  ~  http://linkedin.com/in/martinlanghoff
 - don't be distracted        ~  http://github.com/martin-langhoff
   by shiny stuff

Junio C Hamano· Jun 10, 2020, 17:06 UTC · re: Torsten Bögershausen · lore

Re: osx autocrlf sanity?

Torsten Bögershausen <tboegi@web.de> writes:

Show 13 quoted lines

> On Tue, Jun 09, 2020 at 07:31:23PM -0400, Martin Langhoff wrote:
>> Hi Brian,
>>
>> good question! There is a .gitattributes file, all the files affected
>> have these attributes
>>
>> *.py     text diff=python
>
> That is the important information, that we need.
> Since there is a .gitattributes file, (wich is good),
> you can forget about core.autocrlf (at least for all python files).
> (That should be clear from the documentation of Git,
>  but it could be, that we can make things more clear).

So a "text" attribute trumps the settings of autocrlf? That makes it sound like ...

> There is only one way out of this dilemma:
> renormalize the line endings in the repo (and live a happier life ;-)

... there is another way out, which is to drop "text" attribute?