git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Torsten Bögershausen" <tboegi@web.de>
To: "Yagnatinsky, Mark" <mark.yagnatinsky@bofa.com>
Cc: "'git@vger.kernel.org'" <git@vger.kernel.org>
Subject: Re: suggestion for improved docs on autocrlf
Date: Sun, 11 Aug 2019 14:10:04 +0200	[thread overview]
Message-ID: <20190811121004.guygurnopwwggvsp@tb-raspi4> (raw)
In-Reply-To: <0c1b48c9fad641689ead69fdd9f72d63@bofa.com>

On Fri, Aug 09, 2019 at 03:34:05PM +0000, Yagnatinsky, Mark wrote:
> After correcting spelling of renormalize, the end result of the script you gave is that line endings in working directory are CRLF,
> and in the repo are LF.
> Is that expected?

Yes. "git add" does typically not touch the files on disk at all.

> Surprising?

May be.
Typically the CRLF is done in the .gitattributes file,
which is commited and pushed/pulled between the different
machines.
In opposite, core.autocrlf is just local, and different contributors
may use different settings, leading to all kind of CRLF frustrations.

Having said that, the .gitattributes file is established early in the
lifetime of a project (=repo).
I typically set up the .gitattributes file as the first commit,
before adding any other files.

If, however, the .gitattributes file is added to a repo later
(better late than never), and the developer messes it up for some
reasons, then the original files are still in the working tree on
disk.

Correcttions can be made after looking at 'git ls-files --eol' or
other diagnostics.

>Not sure what you were trying to test there.
There ? I probably lost the script.

>I also fixed my script to use printf, new version is:
> (using copy/paste this time, instead typing from memory like last time; learned my lesson).
>
> mkdir empty
> cd empty
> git init
> git config core.autocrlf false
> printf '1\r\n2' > test.txt
> git add .
> git commit -m test
> git config core.autocrlf input
> cp test.txt t2.txt
> printf 'a\r\nb' > test.txt
> git add .
>
> Thank you for ls-files, I've been resorting to deleting from working directory and then doing a checkout.
> And also thank you for the gem of "od -c"!
> The output of ls-files after running my script is:
>
> i/lf    w/crlf  attr/                   t2.txt
> i/crlf  w/crlf  attr/                   test.txt
>
> So I'm still confused.  Why didn't test.txt lose its CRs while t2.txt did?

This is because the "auto" feature does not change the line endings, when a
file had been commited with CRLF. They may be there on purpose, or not.
Git can not make this decision - the user can.

This is why we have 'git add --renormalize".

  reply	other threads:[~2019-08-11 12:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-07 13:08 suggestion for improved docs on autocrlf Yagnatinsky, Mark
2019-08-08 20:56 ` Torsten Bögershausen
2019-08-08 21:19   ` Yagnatinsky, Mark
2019-08-08 23:08     ` Yagnatinsky, Mark
2019-08-09  3:34       ` Torsten Bögershausen
2019-08-09 15:34         ` Yagnatinsky, Mark
2019-08-11 12:10           ` Torsten Bögershausen [this message]
2019-08-12 13:47             ` Yagnatinsky, Mark
2019-08-12 15:46               ` Junio C Hamano
2019-08-12 15:52                 ` Yagnatinsky, Mark
2019-08-12 17:10               ` Torsten Bögershausen
2019-08-12 18:00                 ` Yagnatinsky, Mark
2019-08-12 18:18                   ` Junio C Hamano
2019-08-12 18:30                     ` Yagnatinsky, Mark
2019-08-13  3:24                     ` Torsten Bögershausen
2019-08-13 15:31                       ` Yagnatinsky, Mark
2019-08-13 15:40                         ` Torsten Bögershausen
2019-08-13 15:44                           ` Yagnatinsky, Mark
2019-08-14 16:28                             ` Yagnatinsky, Mark
2019-08-15  4:56                               ` Yagnatinsky, Mark
2019-08-16  4:20                                 ` Torsten Bögershausen
2019-08-16 19:12                                   ` Yagnatinsky, Mark
2019-08-13 16:40                           ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190811121004.guygurnopwwggvsp@tb-raspi4 \
    --to=tboegi@web.de \
    --cc=git@vger.kernel.org \
    --cc=mark.yagnatinsky@bofa.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).