# Re: \[PATCH\] make description of "core.autocrlf" less ambiguous

- From: Junio C Hamano \<hidden\>
- Date: 2016-06-15 22:48:37 
- List: git
- Page: https://ratatoskr.run/git/2016/06/7460417
- Thread: https://ratatoskr.run/git/2016/06/7460381/t.md

```text
Will Palmer [ref] writes:

> While I did some simple checks to ensure that my basic assumptions about
> how the commands I use daily seem to interact with core.autocrlf, I'll
> easily admit that I don't actually know all the places autocrlf is
> referenced, so I could be completely wrong about what generalizations
> can actually be made in the documentation.

Thanks.

The description uses "reading from the filesystem" vs "writing to the
filesystem" but as you may have noticed, there are cases that we do not
interact with "the filesystem".  Reading (e.g. "hash-object --stdin") from
the standard input may read (e.g. "hash-object --stdin <file") from the
filesystem, but we we may be reading from a "cmd | hash-object --stdin"
pipe.  Similarly, when we write to the standard output, "git to outside
world" direction does not necessarily write to the filesystem.  If you
really want to be anal, these should probably be reworded to "converting
the data from the outside world to the internal canonical representation"
vs "converting the data git has for consumption by the outside world".

The "anal" description, however, is way too verbose, while it might be
technically more correct.  I think the current description would be a
reasonable compromise, as "the filesystem" is the most typical case of
"the outside world"; other than the "the standard input may come from the
pipe" exception, I do not think there is much practical difference (but if
there are more, we might need to sacrifice the readability and go with the
"anal" one).

Very low level plumbing commands deliberately omit the conversion in order
to show the raw data (e.g. cat-file), so it is not correct to reword it to
"when output" as in your version.
```