osx autocrlf sanity?

osx autocrlf sanity?

[Martin Langhoff]

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

Re: osx autocrlf sanity?

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: osx autocrlf sanity?

[Martin Langhoff]

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:
>
> 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

Re: osx autocrlf sanity?

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1081 bytes --]

On 2020-06-09 at 23:31:23, Martin Langhoff wrote:
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: osx autocrlf sanity?

[Martin Langhoff]

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".

regards,



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

RE: osx autocrlf sanity?

[Randall S. Becker]

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.

Re: osx autocrlf sanity?

[Martin Langhoff]

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,


m

On Wed, Jun 10, 2020 at 9:59 AM Randall S. Becker
<rsbecker@nexbridge.com> wrote:
>
> 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

Re: osx autocrlf sanity?

[brian m. carlson]

[-- Attachment #1: Type: text/plain, Size: 1237 bytes --]

On 2020-06-10 at 13:55:12, Martin Langhoff wrote:
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 263 bytes --]

Re: osx autocrlf sanity?

[Torsten Bögershausen]

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).

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.

>
> 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

Re: osx autocrlf sanity?

[Martin Langhoff]

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,


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

Re: osx autocrlf sanity?

[Junio C Hamano]

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

> 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?