Am 28.04.2015 um 21:52 schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
I set none of these. But I do commit CRLF and expect to get CRLF
back. Am I commiting binary files? Am I doing something that Git does
not support? Am I on [my] own?
I think these specific sentences are merely
Hello Hannes,
let me correct my previous statement:
On Mon, Apr 27, 2015 at 08:58:05PM +0200, Johannes Sixt wrote:
When I commit my C source code files with CRLF into the repository
(because I do not set any line ending options or configurations or any
'text' attributes or similar), do I
Am 27.04.2015 um 21:45 schrieb Torsten Bögershausen:
On 04/27/2015 08:58 PM, Johannes Sixt wrote:
Am 27.04.2015 um 08:11 schrieb Stepan Kasal:
Git does not support CRLF as the internal line separator.
If you commit file in binary mode with CRLF, you are on your own.
When I commit my C source
Torsten Bögershausen tbo...@web.de writes:
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
Johannes Sixt j...@kdbg.org writes:
I set none of these. But I do commit CRLF and expect to get CRLF
back. Am I commiting binary files? Am I doing something that Git does
not support? Am I on [my] own?
I think these specific sentences are merely uninformed opinions; if
I ignore and re-read
On 28/04/15 09:28, Junio C Hamano wrote:
Torsten Bögershausentbo...@web.de writes:
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
On 04/27/2015 07:47 PM, Junio C Hamano wrote:
Junio C Hamano gits...@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
On 04/27/2015 08:58 PM, Johannes Sixt wrote:
Am 27.04.2015 um 08:11 schrieb Stepan Kasal:
Git does not support CRLF as the internal line separator.
If you commit file in binary mode with CRLF, you are on your own.
When I commit my C source code files with CRLF into the repository (because I
Hello,
On Sun, Apr 26, 2015 at 10:31:11PM -0700, Junio C Hamano wrote:
[...] the commit you are proposing to revert [4d4813a5]
was a misguided attempt to fix a non issue, [...]
yes, it was this. So I propose to remove the whole commit,
including the test case and add two new test cases.
On Mon, Apr 27, 2015 at 10:47:29AM -0700, Junio C Hamano wrote:
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
Junio C Hamano gits...@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.
Am 27.04.2015 um 08:11 schrieb Stepan Kasal:
Git does not support CRLF as the internal line separator.
If you commit file in binary mode with CRLF, you are on your own.
When I commit my C source code files with CRLF into the repository
(because I do not set any line ending options or
On Sun, Apr 26, 2015 at 8:02 AM, Torsten Bögershausen tbo...@web.de wrote:
A typicall setup under Windows:
s/typicall/typical/
core.eol is CRLF and a file is marked as text in .gitattributes.
After 4d4813a5 git blame no longer works as expected,
every line is annotated as Not Committed Yet,
Torsten Bögershausen tbo...@web.de writes:
Although the intention of 4d4813a5 is good, it breaks
the usual EOL-handling for Windows.
Until we have a better solution, we suggest to revert it.
That makes it sound like you are proposing to rob Peter to pay Paul,
but that is not how we do things
Hello,
thank you Torsten for the patch [I'm the reporter, but could not do
it myself]
-test_expect_success 'blaming files with CRLF newlines' '
+test_expect_failure 'blaming files with CRLF newlines in repo,
core.autoclrf=input' '
Shouldn't the old test be rather removed?
It deals with an
15 matches
Mail list logo
