Re: [PATCH v2] docs: rewrite the documentation of the text and eol attributes

From: Alex Henrie <alexhenrie24@gmail.com>
Date: May 1, 2023, 00:40 UTC
Message-ID: <CAMMLpeTWxLKtrXxLWY=3mCwh2i8jhQ7ZcivdxpY36rDBpNtK8A@mail.gmail.com>
In-Reply-To: <xmqqcz3m9ch1.fsf@gitster.g>

On Sat, Apr 29, 2023 at 11:16 PM Junio C Hamano <gitster@pobox.com> wrote:

Show 9 quoted lines

>
> Alex Henrie <alexhenrie24@gmail.com> writes:
>
> > The new text may be slightly redundant, but it makes the
> > important part crystal clear.
>
> I tend to disagree and think it is a bit too redundant, but we do
> not have to agree on everything---after all you are doing all the
> work, and it is your motivation and your topic.

I just now realized that `eol=crlf` works when `text` is unspecified. In that light, the phrase "on checkin and possibly also checkout" seems to go a little too far towards implying that the eol attribute and core.autocrlf config variable depend on the text attribute being set. Omitting that phrase would leave the introduction with a better balance between precision and brevity, and the remainder of the documentation would still be there to flesh out the details.

Show 9 quoted lines

> > Then again, maybe the fact that the `text` attribute does not
> > normalize CR line endings is a bug in Git, and we shouldn't advertise
> > it in the documentation as if it were intended behavior. What do you
> > think?
>
> Just not mentioning CRLF specifically would be sufficient.  When
> (and if) somebody actually comes and complains, we can say "CR
> delimited files are not considered text these days, we aren't doing
> MacOS System 7" ;-).

I don't think I would dare say "CR-delimited text is not text" to a retro computing enthusiast. But I'm fine with not mentioning CRLF in this sentence, and when the angry mob shows up on my doorstep, I will just send them your way ;-)

-Alex