git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Alex Henrie <alexhenrie24@gmail.com>
Cc: git@vger.kernel.org, eyvind.bernhardsen@gmail.com, tboegi@web.de
Subject: Re: [PATCH v2] docs: rewrite the documentation of the text and eol attributes
Date: Sat, 29 Apr 2023 22:16:10 -0700	[thread overview]
Message-ID: <xmqqcz3m9ch1.fsf@gitster.g> (raw)
In-Reply-To: <CAMMLpeQB1zdTEWd+=d0kaKwpzax093iLTuytZtvn0nTSJ2xT4A@mail.gmail.com> (Alex Henrie's message of "Sat, 29 Apr 2023 13:19:00 -0600")

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.

> 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" ;-).

> The phrase "if necessary" would be a bit confusing. What makes
> conversion on checkin "necessary"? The reader would wonder if it
> depends on the Git config and the platform like conversion on checkout
> does.
>
> Would you be OK with your proposed wording minus "if necessary"?

I added it only because it would not be necessary if the original
already uses LF line endings, in which you do not have to do any
converison.  As long as it is clear that no conversion happens in
such a case without saying, I am perfectly fine to drop it.

>> There are some exception handling in the code for odd cases like the
>> contents with mixed line endings, a path set to use LF but the file
>> actually has CRLF, etc.  While they are worth describing, I wonder
>> if they should be done in a separate paragraph.
>
> Probably best done in a separate patch after this rewrite is done.

What I meant was that that your "unless text=auto" and everything
after it was one of thoese exception handling that should be dealt
in a separate paragraph.  Leaving it as a follow-on work is fine.

> Wow, that was a LOT of feedback on a relatively short piece of text.
> Are you sure you don't want to rewrite the documentation yourself? ;-)

Absolutely not.  It is not my itch to update this document.

My itch is to make sure any change makes the resulting text better
than the previous one ;-).

Thanks.

  reply	other threads:[~2023-04-30  5:19 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-21  5:56 [PATCH] docs: clarify how the text and text=auto attributes are different Alex Henrie
2023-04-21 16:35 ` Junio C Hamano
2023-04-21 18:25 ` Torsten Bögershausen
2023-04-26 13:18   ` Alex Henrie
2023-04-28  4:22 ` [PATCH v2] docs: rewrite the documentation of the text and eol attributes Alex Henrie
2023-04-28 18:05   ` Junio C Hamano
2023-04-29 19:19     ` Alex Henrie
2023-04-30  5:16       ` Junio C Hamano [this message]
2023-05-01  0:40         ` Alex Henrie
2023-04-30 13:19   ` Torsten Bögershausen
2023-04-30 23:43     ` Alex Henrie

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=xmqqcz3m9ch1.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=alexhenrie24@gmail.com \
    --cc=eyvind.bernhardsen@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=tboegi@web.de \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).