All of lore.kernel.org
 help / color / mirror / 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: Mon, 12 Aug 2019 19:10:49 +0200	[thread overview]
Message-ID: <20190812171049.ydec3nsmkt2xplhd@tb-raspi4> (raw)
In-Reply-To: <64c0a35825af4ff3956c6c9a5fb748bb@bofa.com>

On Mon, Aug 12, 2019 at 01:47:18PM +0000, Yagnatinsky, Mark wrote:
> Wait a second... suppose a file is committed with CRLF line endings.
> You're saying that even if I have autocrlf set to "input" or "auto", the file will never get "converted" to LF format unless I explicitly renormalize?

Yes.

> That sounds like a fairly sensible behavior, but it's not what I've observed in the past at all!
> There have been plenty of times when I had "autocrlf" set to input which resulted in me changing line endings on commit I had no intention of changing!
> Indeed, the whole reason I was looking at the git docs recently is that this happened again and I was trying to make it stop happening!
> Or is that not what you meant?
>
Only changing core.autocrlf to input will not change the line endings in the repo.
That is intentional and allows to to keep core.autocrlf and jump force-and-back in
the history by checking out older versions or later versions.

That is why I would recommend a .gitattributes file,
which travels with the commits and through push and pull.

My feeling is that the docemntation for core.autocrlf should be:
This setting is deprecated. Use a .gitattributes file instead,
and please see the documentation.
But that is clearly debatable.


  parent reply	other threads:[~2019-08-12 17: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
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 [this message]
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

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

  git send-email \
    --in-reply-to=20190812171049.ydec3nsmkt2xplhd@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. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.