git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Torsten Bögershausen" <tboegi@web.de>
To: Jeff King <peff@peff.net>
Cc: Sergey Lukashev <lukashev.s@ya.ru>,
	"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: unclear docs
Date: Tue, 29 Jan 2019 07:38:10 +0000	[thread overview]
Message-ID: <20190129073810.23op5qaibyj2amwq@tb-raspi4> (raw)
In-Reply-To: <20190128183117.GA13165@sigill.intra.peff.net>

On Mon, Jan 28, 2019 at 01:31:17PM -0500, Jeff King wrote:
> On Mon, Jan 28, 2019 at 09:12:00PM +0300, Sergey Lukashev wrote:
>
> > Thank you. Does the paragraph about core.eol refers to the text
> > attribute? It's written 'property' there. I was thinking it means
> > whether git thinks file is text, using .gitattributes OR otherwise.
> > Maybe changing this word will make it clearer?
>
> Yeah, I think the word "property" is unnecessarily confusing. Here's
> another patch (meant to go on top of the other).

The property was originally meant to say:
- Either the "text" attribute is set in .gitattributes
  or
- The "text=auto" attribute is set in .gitattributes and
  Git auto-detects the file as text (and not as binary).



>
> -- >8 --
> Subject: [PATCH] docs/config: clarify "text property" in core.eol
>
> The word "property" is less clear than "attribute", which is used
> elsewhere in the (surprise!) gitattributes documentation. So let's use
> that.
>
> While we're here, let's make the paragraph a little easier to read by
> de-emphasizing the "when core.autocrlf is false" bit. Putting it in the
> first sentence obscures the main content, and many readers won't care
> about autocrlf (i.e., anyone who is just following the gitattributes(7)
> advice, which mainly discusses "text" and "core.eol").
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
>  Documentation/config/core.txt | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/config/core.txt b/Documentation/config/core.txt
> index d0e6635fe0..69c73ffe30 100644
> --- a/Documentation/config/core.txt
> +++ b/Documentation/config/core.txt
> @@ -121,11 +121,12 @@ core.quotePath::
>
>  core.eol::
>  	Sets the line ending type to use in the working directory for
> -	files that have the `text` property set when core.autocrlf is false.
> +	files that have the `text` attribute.
>  	Alternatives are 'lf', 'crlf' and 'native', which uses the platform's
>  	native line ending.  The default value is `native`.  See
>  	linkgit:gitattributes[5] for more information on end-of-line
> -	conversion.
> +	conversion. Note that this value is ignored if `core.autocrlf`
> +	is set to `true`.

Should that be
 > +	conversion. Note that this value is ignored if `core.autocrlf`
 > +	is set to `true` or `input`.

As we look at convert.c:

static int text_eol_is_crlf(void)
{
  if (auto_crlf == AUTO_CRLF_TRUE)
    return 1;
  else if (auto_crlf == AUTO_CRLF_INPUT)
    return 0;
  if (core_eol == EOL_CRLF)
    return 1;
  if (core_eol == EOL_UNSET && EOL_NATIVE == EOL_CRLF)
    return 1;
  return 0;
}


  reply	other threads:[~2019-01-29  7:38 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-27  9:58 unclear docs Sergey Lukashev
2019-01-27 11:55 ` Sergey Lukashev
2019-01-28 16:09   ` Jeff King
2019-01-28 18:12     ` Sergey Lukashev
2019-01-28 18:31       ` Jeff King
2019-01-29  7:38         ` Torsten Bögershausen [this message]
2019-01-29 10:28           ` Sergey Lukashev
2019-01-29 12:40           ` [PATCH v2 0/2] eol/autocrlf doc clarifications Jeff King
2019-01-29 12:41             ` [PATCH v2 1/2] doc/gitattributes: clarify "autocrlf overrides eol" Jeff King
2019-01-29 12:41             ` [PATCH v2 2/2] docs/config: clarify "text property" in core.eol Jeff King
2019-01-28 17:31   ` unclear docs Torsten Bögershausen
2019-01-28 16:06 ` Jeff King
2019-01-28 18:30   ` Junio C Hamano
2019-01-28 18:32     ` Jeff King
2019-01-28 20:16       ` Sergey Lukashev
2019-01-28 20:46         ` Jeff King

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=20190129073810.23op5qaibyj2amwq@tb-raspi4 \
    --to=tboegi@web.de \
    --cc=git@vger.kernel.org \
    --cc=lukashev.s@ya.ru \
    --cc=peff@peff.net \
    /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).