Having been bitten by autocrlf multiple times, I am not so sure why this change is needed.
Having it set to false, git will not modify the line endings during the round trip of tfs -> git -> tfs

After your change, files which have LF (UNIX style line endings) by intention in TFS are now put back into
TFS with CRLF (Windows style line endings). So I would not recommend for changing the default,
as this might be confusing for new users.

If you still want to proceed with your idea, you should at least update the documentation to mention
the new defaults, e.g. doc/config.md contains an entry that core.autocrlf is set to false by default.

I agree that the default doesn't need to be changed, I can revert those changes. The main issue is that git-tfs uses Blob.GetContentStream() instead of Blob.GetContentStream(FilteringOptions). This api is not clear in libgit2sharp, but using the first overload will get the raw file data without converting line endings if autocrlf is set to true.

        /// <summary>
        /// Gets the blob content in a <see cref="Stream"/>.
        /// </summary>
        public virtual Stream GetContentStream();

        /// <summary>
        /// Gets the blob content in a <see cref="Stream"/> as it would be
        /// checked out to the working directory.
        /// <param name="filteringOptions">Parameter controlling content filtering behavior</param>
        /// </summary>
        public virtual Stream GetContentStream(FilteringOptions filteringOptions);

Can someone please merge this PR? This issue has been known (with a known fix) for years now (issue #528). I have been forced to use a fork with this fix, and then absentmindedly replaced it with the latest from the mainline, and got bit by this issue again..

@pmiossec Would you mind taking a look at this?

In fact, seems ok...

Thanks a lot.

@m-akinc

Can someone please merge this PR? This issue has been known (with a known fix) for years now (issue #528).

As I could not test anymore complex PR, I wait to have comments by users testing some PR.

I have been forced to use a fork with this fix, and then absentmindedly replaced it with the latest from the mainline, and got bit by this issue again.

Which fork? your own?
Do you have other fixes that you use?

It was not my current fork (the one I used for PR #1249 ). I had forked over a year ago to include two yet unmerged bug fixes: this line ending one, and another related to an out-of-memory error you fixed in PR #1138 . I had been using that build until earlier this week. Then I ran into the subdirectory delete bug, and I created a fresh fork, fixed the bug, and started using that build. But of course, it was missing this line ending fix.

Ok. Thanks.