git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: Robert Dailey <rcdailey.lists@gmail.com>, Git <git@vger.kernel.org>
Subject: Re: 'eol' documentation confusion
Date: Mon, 22 Jun 2015 09:11:55 -0700	[thread overview]
Message-ID: <xmqqr3p3iuyc.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <5587AAB2.80305@web.de> ("Torsten Bögershausen"'s message of "Mon, 22 Jun 2015 08:26:58 +0200")

Torsten Bögershausen <tboegi@web.de> writes:

> eol=lf or eol=crlf are the only useful settings.
> Everything else is ignored because it does not make sense.
>
> See convert.c:
> static enum eol git_path_check_eol()

That makes me wonder...

The original reasoning behind the current behaviour that we ignore
unknown values given to configuration variables and attributes is so
that people can use the same file that has values that are
understood by newer versions of Git with older versions of Git.

You may be trying the eol=cleverLF setting introduced in Git version
47-prerelease by adding it to .git/info/attributes, and may have
found it useful.  But you may also have to use the same repository
on another machine that you didn't install that future version of
Git over the network filesystem.  Barfing and not proceeding when we
see unknown eol=cleverLF does not sound like a nice thing to do,
which is why we just ignore and behave as if the setting was not
there.

Ideally, however, I think we should ignore an unknown setting as
long as it does not matter (i.e. we do not come to the codepath that
wants to know eol settings for the path, e.g. running "git log" to
show only the commit log messages and the topology of the history),
but we should error out when the unknown setting possibly matters
(i.e. we do need the eol setting for the path in order to correctly
convert the contents to end-user's liking).

Thoughts (and patches ;-)?

  reply	other threads:[~2015-06-22 16:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-21 14:04 'eol' documentation confusion Robert Dailey
2015-06-21 14:16 ` Robert Dailey
2015-06-22  6:26   ` Torsten Bögershausen
2015-06-22 16:11     ` Junio C Hamano [this message]
2015-06-25 15:31       ` Torsten Bögershausen

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqr3p3iuyc.fsf@gitster.dls.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=rcdailey.lists@gmail.com \
    --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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).