From: Junio C Hamano <gitster@pobox•com>
To: "Torsten Bögershausen" <tboegi@web•de>
Cc: git@vger•kernel.org
Subject: Re: [PATCH 2/2] t0027: combinations of core.autocrlf, core.eol and text
Date: Mon, 30 Jun 2014 11:27:42 -0700 [thread overview]
Message-ID: <xmqq61jiz201.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <53AFB38E.8000401@web.de> ("Torsten Bögershausen"'s message of "Sun, 29 Jun 2014 08:34:54 +0200")
Torsten Bögershausen <tboegi@web•de> writes:
> Historically there are 3 different parameters controlling how line endings
> are handled by Git:
> - core.autocrlf
> - core.eol
> - the "text" attribute in .gitattributes
>
> There are different types of content:
> - (1) Files with only LF
> - (2) Files with only CRLF
> - (3) Files with mixed LF and CRLF
> - (4) Files with LF and/or CRLF with CR not followed by LF
> - (5) Files which are binary (e.g. have NUL bytes)
>
> Recently the question came up, how files with mixed EOLs are handled by Git
> (and libgit2) when they are checked out and core.autocrlf=true.
I have a slight suspicion that it may be better to leave behaviour
on some nonsensical combinations (e.g. 3 and 4) as "unspecified",
which would mean we shouldn't be able to pick between
test_expect_success and test_expect_failure for some of them.
> +test_description='CRLF conversion all combinations'
> +
> +check_files_in_ws()
> +{
(minor) Please have SP between "ws" and "()".
> +(
> + type od >/dev/null &&
> + printf "line1Q\r\nline2\r\nline3" | q_to_nul >CRLF_nul &&
> + cat >expect <<-EOF &&
> + 0000000 l i n e 1 \0 \r \n l i n e 2 \r \n l
> + 0000020 i n e 3
> + 0000024
> +EOF
> + od -c CRLF_nul | sed -e "s/[ ][ ]*/ /g" -e "s/ *$//" >actual
> + test_cmp expect actual &&
> + rm expect actual
> +) || {
> + skip_all="od not found or od -c not usable"
> + exit 0
> + test_done
> +}
I am not sure how cast-in-stone portable "od -c" output is across
platforms in practice. You can use tr to convert NUL, CR and LF to
some distinctive and otherwise unused character, just like you use
q_to_nul to map NUL to "Q" already. And that would allow you to
forget about such portability issues.
> +test_expect_success 'setup master' '
> + echo >.gitattributes &&
> + git checkout -b master &&
> + git add .gitattributes &&
> + git commit -m "add .gitattributes" "" &&
> + printf "line1\nline2\nline3" >LF &&
> + printf "line1\r\nline2\r\nline3" >CRLF &&
> + printf "line1\r\nline2\nline3" >CRLF_mix_LF &&
> + printf "line1\nline2\rline3" >LF_mix_CR &&
> + printf "line1\r\nline2\rline3" >CRLF_mix_CR &&
> + printf "line1Q\nline2\nline3" | q_to_nul >LF_nul
I do not see why you would want files that end with incomplete lines
for these. Please have the line-end for the last line in them.
prev parent reply other threads:[~2014-06-30 18:28 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-29 6:34 [PATCH 2/2] t0027: combinations of core.autocrlf, core.eol and text Torsten Bögershausen
2014-06-30 18:27 ` Junio C Hamano [this message]
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=xmqq61jiz201.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=tboegi@web$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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