On 2021-10-20 at 01:21:40, Eric Sunshine wrote: > On Tue, Oct 19, 2021 at 9:06 PM brian m. carlson > wrote: > > In the FAQ, we tell people how to use the text attribute, but we fail to > > explain what to do with the eol attribute. As we ourselves have > > noticed, most shell implementations do not care for carriage returns, > > and as such, people will practically always want them to use LF endings. > > Similar things can be said for batch files on Windows, except with CRLF > > endings. > > > > Since these are common things to have in a repository, let's help users > > make a good decision by recommending that they use the gitattributes > > file to correctly check out the endings. > > > > In addition, let's correct the cross-reference to this question, which > > originally referred to "the following entry", even though a new entry > > has been inserted in between. The cross-reference notation should > > prevent this from occurring and provide a link in formats, such as HTML, > > which support that. > > > > Signed-off-by: brian m. carlson > > --- > > diff --git a/Documentation/gitfaq.txt b/Documentation/gitfaq.txt > > @@ -464,14 +465,25 @@ references, URLs, and hashes stored in the repository. > > +With text files, Git will generally the repository contains LF endings in the > > +repository, and will honor `core.autocrlf` and `core.eol` to decide what options > > +to use when checking files out. You can also override this by specifying a > > +particular line ending such as `eol=lf` or `eol=crlf` if those files must always > > +have that ending (e.g., for functionality reasons). > > The first sentence in the paragraph is unparseable. Yes, I think perhaps I omitted the word "ensure". And I should reflect that they should have that ending in the working tree, which I neglected to mention. > > +# Ensure all shell files end up with LF endings and all batch files end up > > +# with CRLF endings in the working tree and both end up with LF in the repo. > > +*.sh text eol=lf > > +*.bat text eol=crlf > > Maybe: s/end up with/have/g Great. That does read more clearly and succinctly. I'll include those fixes in a reroll. -- brian m. carlson (he/him or they/them) Toronto, Ontario, CA