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
Am 28.04.2015 um 21:52 schrieb Junio C Hamano:
Johannes Sixt 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 uninforme
Johannes Sixt 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 what peop
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
On 28/04/15 09:28, Junio C Hamano wrote:
Torsten Bögershausen 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 &&
Torsten Bögershausen 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
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
> Com
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 (beca
On 04/27/2015 07:47 PM, Junio C Hamano wrote:
> Junio C Hamano 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 beha
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 configura
Junio C Hamano 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 th
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.
D
Torsten Bögershausen 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 around here
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
On Sun, Apr 26, 2015 at 8:02 AM, Torsten Bögershausen 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",
>
A typicall setup under Windows:
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",
even though the working directory is clean.
commit 4d4813a5 removed the conversion in blame.c
16 matches
Mail list logo
