From: "Torsten Bögershausen" <tboegi@web.de>
To: "Torsten Bögershausen" <tboegi@web.de>,
"Benkstein, Frank" <frank.benkstein@sap.com>,
"git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: git blame breaking on repository with CRLF files
Date: Sun, 9 Aug 2015 22:19:58 +0200 [thread overview]
Message-ID: <55C7B5EE.7060908@web.de> (raw)
In-Reply-To: <55C59A9B.9000808@web.de>
On 2015-08-08 07.58, Torsten Bögershausen wrote:
> On 2015-08-07 18.32, Benkstein, Frank wrote:
>> Hello,
>>
>> I am working working on Linux and am examining code in a git repository I do
>> not know much about. I am only looking at files, not changing anything. On
>> some files in the repository I get "00000000 (Not Committed Yet" for all lines
>> when running "git blame". I checked with "git status", "git reset", "git
>> clean" that the files are indeed in the repository and unmodified. I noticed
>> that this only happens with git v2.5.0. With git v2.4.0 it looks correct, i.e.
>> the output has proper commit ids, Author names and dates.. With "git bisect" I
>> tracked this down to the following commit:
>>
>> commit 4bf256d67a85bed1e175ecc2706322eafe4489ca (HEAD, refs/bisect/bad)
>> Author: Torsten Bögershausen <tboegi@web.de>
>> Date: Sun May 3 18:38:01 2015 +0200
>>
>> blame: CRLF in the working tree and LF in the repo
>>
>> Digging further, it seems that most files in the repository are checked in with
>> CRLF line endings. In my working tree these are checked out as LF
> Do I understand it right that you have files in the repo with CRLF ?
> And these files are checked out with LF in the working tree ?
> Are the files marked with .gitattributes ?
> Or does the file have mixed line endings ?
>
> (Unless I missed something: Git never strips CRLF into LF at checkout,
> so I wonder how you ended up in this situation)
>
> Is there a way to reproduce it?
>
Actually I could reproduce the following:
CRLF in repo, CRLF in working tree, core.autocrlf= true.
This is an old limitation (or call it bug), which has been there for a long
time, (I tested with Git v1.7.0 from 2010).
Thanks for the report, we will see if anybody is able to fix it.
I can probably contribute some test cases.
>> seems to be the exact opposite situation of what the commit is trying to
>> address. When I set "core.autocrlf" to "false" I also get the correct behavior
>> of "git blame" - this is a workaround as long as I do not have to actually
>> modify anything.
>>
>> Best regards,
>> Frank.
next prev parent reply other threads:[~2015-08-09 20:20 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-07 16:32 git blame breaking on repository with CRLF files Benkstein, Frank
2015-08-08 5:58 ` Torsten Bögershausen
2015-08-09 20:19 ` Torsten Bögershausen [this message]
2015-08-10 8:36 ` Benkstein, Frank
2015-08-10 23:54 ` brian m. carlson
2015-08-10 18:48 ` Junio C Hamano
2015-08-10 20:22 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55C7B5EE.7060908@web.de \
--to=tboegi@web.de \
--cc=frank.benkstein@sap.com \
--cc=git@vger.kernel.org \
/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 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 NNTP newsgroup(s).