Re: suggestion for improved docs on autocrlf

From: Torsten Bögershausen <tboegi@web.de>
Date: Aug 13, 2019, 03:24 UTC
Message-ID: <20190813032452.qg2ufgljm4bjeznr@tb-raspi4>
In-Reply-To: <xmqqo90u9ric.fsf@gitster-ct.c.googlers.com>

On Mon, Aug 12, 2019 at 11:18:35AM -0700, Junio C Hamano wrote:

Show 6 quoted lines

> "Yagnatinsky, Mark" <mark.yagnatinsky@bofa.com> writes:
>
> > ...  Assuming the repo has no .gitattributes,
> > is it possible to predict what line endings sample.txt will end up with in my repo?
> > Or does it depend on more information than what I've just written?
>

> Binary packagers can ship custom attributes and config that applies
> globally to the installation, which may affect operations in all of
> your repositories, can't they?

Let me try to split my answer into 3 parts:
- A Git distribution can ship with a global attributes file, but I am not aware of any
  distribution doing this.
  Especially Git for Windpws does not add any (global) .gitattributes file somewhere,
  as far as I know.
- The default value for the global core.autocrlf is typically unset in all
  Unix-like distributions, which does the same as core.autocrlf=false.
- The installer for Git for Windows allows the user to choose what the global
  core.autocrlf should be (false, true, input).
  The help text of the installer mentions what
  e.g. "false" means (line endings "as is"),
  and I don't rember the text for "true" and "input"  out of my head.

Now back to the original question:

Person A creates a repo with core.autocrlf=false and commite sample.txt with CRLF. Person B clones that repo with CRLF in the repo. When the worktree is checked out, sample.txt will have CRLF. Always.

Even if B uses core.autocrlf=input, sample.txt will keep the CRLF when it is commited. If the line endings need to be changed, there are 2 ways: Either user B runs dos2unix and commits file with LF. Or user B runs `git add --renormalize` sample.txt. That needs a `rm sample.txt && git checkout sample.txt` to update the working tree.

All this is predictable. A fresh clone does not have any "modified files"; all files with CRLF stay with CLRF unless they are normalized.

Our documentation mentions "files that any contributor introduces to the repository"

Is that part understandalble and the distincion between "existing" and "new" files clear enough ?