From: "Torsten Bögershausen" <tboegi@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org,
Johannes Schindelin <johannes.schindelin@gmx.de>,
kasal@ucw.cz, sandals@crustytoothpaste.net
Subject: Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo
Date: Mon, 27 Apr 2015 21:40:48 +0200 [thread overview]
Message-ID: <553E90C0.4070103@web.de> (raw)
In-Reply-To: <xmqqa8xtxy32.fsf@gitster.dls.corp.google.com>
On 04/27/2015 07:47 PM, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> I suspect (I haven't looked very carefully for this round yet to be
>> sure, though) that it may turn out that the commit you are proposing
>> to revert was a misguided attempt to "fix" a non issue, or to break
>> the behaviour to match a mistaken expectation. If that is the case
>> then definitely the reversion is a good idea, and you should argue
>> along that line of justification.
>>
>> We'd just be fixing an old misguided and bad change in such a case.
> The original says this:
>
> blame: correctly handle files regardless of autocrlf
>
> If a file contained CRLF line endings in a repository with
> core.autocrlf=input, then blame always marked lines as "Not
> Committed Yet", even if they were unmodified. Don't attempt to
> convert the line endings when creating the fake commit so that blame
> works correctly regardless of the autocrlf setting.
>
> Reported-by: Ephrim Khong <dr.khong@gmail.com>
> Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
>
> But if autocrlf=input, then the end-user expectation is to keep the
> in-repository data with LF line endings. If your tip-of-the-tree
> commit incorrectly has CRLF line endings, and if you were going to
> commit what is in the working tree on top, you would be correcting
> that mistake by turning the in-repository data into a text file with
> LF line endings, so "Not Committed Yet" _is_ the correct behaviour.
>
> So I think that the reverting that change is the right thing to do.
> It really was a change to break the behaviour to match a mistaken
> expectation, I would have to say.
Besides a better commit message (suggestions welcome),
What do you think about the following test cases for a V2 patch ?
test_expect_success 'create blamerepo' '
test_create_repo blamerepo &&
(
cd blamerepo &&
printf "testcase\r\n" >crlffile &&
git -c core.autocrlf=false add crlffile &&
git commit -m "add files" &&
git -c core.autocrlf=false blame crlffile >crlfclean.txt
)
'
test_expect_success 'blaming files with CRLF newlines in repo, core.autoclrf=input' '
(
cd blamerepo &&
git -c core.autocrlf=input blame crlffile >actual &&
grep "Not Committed Yet" actual
)
'
test_expect_success 'blaming files with CRLF newlines core.autocrlf=true' '
(
cd blamerepo &&
git -c core.autocrlf=true blame crlffile >actual &&
test_cmp crlfclean.txt actual
)
'
test_expect_success 'blaming files with CRLF newlines core.autocrlf=false' '
(
cd blamerepo &&
git -c core.autocrlf=false blame crlffile >actual &&
test_cmp crlfclean.txt actual
)
'
next prev parent reply other threads:[~2015-04-27 19:44 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-26 12:02 [PATCH/RFC] blame: CRLF in the working tree and LF in the repo Torsten Bögershausen
2015-04-26 18:36 ` Eric Sunshine
2015-04-27 4:39 ` Stepan Kasal
2015-04-27 5:31 ` Junio C Hamano
2015-04-27 6:11 ` Stepan Kasal
2015-04-27 18:58 ` Johannes Sixt
2015-04-27 19:45 ` Torsten Bögershausen
2015-04-28 18:42 ` Johannes Sixt
2015-04-28 19:52 ` Junio C Hamano
2015-04-28 20:19 ` Johannes Sixt
2015-04-28 21:58 ` Stepan Kasal
2015-04-27 17:47 ` Junio C Hamano
2015-04-27 19:40 ` Torsten Bögershausen [this message]
2015-04-28 7:28 ` Junio C Hamano
2015-04-28 7:40 ` Torsten Bögershausen
2015-04-28 1:17 ` brian m. carlson
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=553E90C0.4070103@web.de \
--to=tboegi@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johannes.schindelin@gmx.de \
--cc=kasal@ucw.cz \
--cc=sandals@crustytoothpaste.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.