Use CRLF as EOL

[akihikodaki]

GenerateMetadataFromCSUnitTest.cs and possibly more assume their EOLs are CRLF.

[yufeih]

@superyyrrzz , could you provide some assistance on this pull request?

[superyyrrzz]

@akihikodaki Could you provide more background about this pull request? We can see this change is failing CI for now.

[akihikodaki]

@superyyrrzz Well, I tried to use text=auto eol=crlf, which was supposed to be equal to core.autocrlf config, in .gitattributes, but apparently Git on the CI system is too old to support one. (The earliest version supporting it is 2.10.0, but the CI has 2.6.2.windows.1.)

We have three options to solve the issue:

1. Update Git. (Sorry but it's up to you.)
2. List all binary patterns.
3. Abandon .gitattributes and document a workaround.

[superyyrrzz]

@akihikodaki Option 1 should be the cleanest solution. I will update git on CI. It seems 2.6.2 is a too old version...

[superyyrrzz]

Latest version (2.19.1) installed. You can continue your change. @akihikodaki

[akihikodaki]

It looks like failing because of a bug in build.ps1.

    if ($commitInfo.length -gt 1) {
        $revision = (Get-Date -UFormat "%Y%m%d").Substring(2) + $commitInfo[1].PadLeft(3, '0')
    }
    else {
        $revision = '000000000'
    }

$commitInfo.length -gt 1 is true now. I wonder why (Get-Date -UFormat "%Y%m%d").Substring(2) is added only in such a case. Any idea?

[superyyrrzz]

This is a logic to calculate package name. If it got v2.40-17-g9f9b0831b by git describe --tags, then it will split by - and use 017 as part of the package name. This check is to make sure the number is actually got.

Why do you think here is a bug? I see from the CI report that it still failed when extracting metadata.

[akihikodaki]

I was wrong but I think I identified the real cause. I checked the end of the build log to find it says:

[05:35:24][Step 3/3] The special version part cannot exceed 20 characters.
[05:35:24][Step 3/3] Error 1: C:\Users\build\AppData\Local/Nuget/Nuget.exe pack src/nuspec/MarkdownMigrateTool/MarkdownMigrateTool.nuspec -Version 2.41.0-b-181109019-gfeb6ab28d -OutputDirectory artifacts/Release -BasePath C:\BuildAgent\work\130feb8a19fc2a14\docfx/target/Release/MarkdownMigrateTool

Indeed b-181109019-gfeb6ab28d has 22 characters. I thought the code I pointed out earlier caused the issue. But it was actually because of a breaking change of Git. The release note of Git 2.11.0 says:

• The default abbreviation length, which has historically been 7, now scales as the repository grows, using the approximate number of objects in the repository and a bit of math around the birthday paradox. The logic suggests to use 12 hexdigits for the Linux kernel, and 9 to 10 for Git itself.

You have to drop some information from the special version part. What will you drop then?

[superyyrrzz]

@akihikodaki As this string is used as part of the package version, the length of each - separated part should remain same, so that to key string comparison result stable. I suggest to change last part back to 7 characters $abbrev = $commitInfo[2].Substring(0, 7)

docfx/build.ps1

Line 139 in 9f9b08e

$abbrev = $commitInfo[2]

[akihikodaki]

The suggested change was applied as e587af6 and it finally passed the CI.

[superyyrrzz]

@akihikodaki Thank you for your contribution! /cc @928PJY