Fixed line endings in 'largest-series-product' files

[felix91gr]

As per #452

Now they have just LF

[jpreese]

I checked out your branch and all of the line endings are still CRLF. Actually, all of my line endings for all files are CRLF.

[felix91gr]

Mmm. Okay, I'm reading git's messages wrongly.

Thanks! I'll see and check what really happened.

[felix91gr]

Okay, this time I'm pretty sure I fixed them.

@jpreese could you corroborate? :)

[jpreese]

I think I would just need to do some research into this topic. Right now, all of my line endings are in CRLF. So from my point of view, it doesn't make a whole lot of sense to merge this in. Two files would have LF line endings, and the rest would be CRLF.

Maybe @ErikSchierboom or @robkeim are more versed in Git and line endings across operating systems?

[felix91gr]

Right now, all of my line endings are in CRLF

Wait, what? Really?
How does... Hmm 🤔 how does your git accept those? Does it give you a warning or something? Also, every file (except these two troublemakers) that isn't pointed out in the .gitattributes is checked out with only LF. How do our two versions coexist?

My guess is that, since git says this:

warning: CRLF will be replaced by LF in exercises/largest-series-product/Example.cs. The file will have its original line endings in your working directory.

That must mean that git internally and externally represents them in a different way?

But yeah, given how the repo's files are in your computer, we need experts' advice here... because I don't know what's up either 🤷‍♂️

[ErikSchierboom]

Right now, all of my line endings are in CRLF

Well, actually this makes total sense, as this is precisely what the *.cs text=auto diff=csharp line in our .gitattributes file intends to do: it normalizes the line endings on your local file system. That means that for people on Unix systems, the line endings should all be LF's.

And now for the problem @felix91gr is having. Are you having that problem on checkout or only when running the test generator?

One problem might be that our test generator doesn't output line endings in the host OS'es native line ending format. For example, at a couple of places we use a hardcoded \n value (see https://github.com/exercism/csharp/blob/master/generators/Output/ValueFormatter.cs#L71), which we should all change to Environment.Newline. I also don't know how dotliquid handles line endings, which might also be problematic.

My suggestion is as follows: @felix91gr can you confirm that the problem only happens after running the test generator?

[jpreese]

I just generated all of the tests and looked at some \n cases with the ValueFormatter, and all of my newlines were still CRLF. We output \n a lot for string variables, but that shouldn't impact be a true LF in the file itself.

[felix91gr]

Are you having that problem on checkout or only when running the test generator?

@ErikSchierboom so this is what I get when I just do checkout of master:

git clone https://github.com/exercism/csharp/ csharp_checkout
Cloning into 'csharp_checkout'...
remote: Counting objects: 4990, done.
remote: Compressing objects: 100% (34/34), done.
remote: Total 4990 (delta 15), reused 27 (delta 9), pack-reused 4947
Receiving objects: 100% (4990/4990), 1.67 MiB | 1.23 MiB/s, done.
Resolving deltas: 100% (3021/3021), done.
Checking connectivity... done.
~/D/P/exercism $ cd csharp_checkout/
~/D/P/e/csharp_checkout (master) $ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   exercises/largest-series-product/Example.cs
	modified:   exercises/largest-series-product/LargestSeriesProductTest.cs

no changes added to commit (use "git add" and/or "git commit -a")
~/D/P/e/csharp_checkout (master) $ file exercises/largest-series-product/Example.cs 
exercises/largest-series-product/Example.cs: ASCII text, with CRLF line terminators
~/D/P/e/csharp_checkout (master) $ 
file exercises/largest-series-product/LargestSeriesProductTest.cs 
exercises/largest-series-product/LargestSeriesProductTest.cs: ASCII text, with very long lines, with CRLF line terminators
~/D/P/e/csharp_checkout (master) $ 

The CRLF are definitely there in the repo.

Okay, now after running the generators:

~/D/P/e/csharp_checkout (master) $ cd generators/
~/D/P/e/c/generators (master) $ dotnet run
[17:11:01 INF] Re-generating test classes...
[17:11:01 INF] Updating repository to latest version...
[17:11:06 INF] Updated repository to latest version.
[17:11:06 INF] Generated tests for acronym exercise in ../exercises/acronym/AcronymTest.cs
[17:11:06 INF] Generated tests for allergies exercise in ../exercises/allergies/AllergiesTest.cs
.
.
.
[17:11:07 INF] Generated tests for complex-numbers exercise in ../exercises/complex-numbers/ComplexNumbersTest.cs
.
.
.
[17:11:07 INF] Generated tests for isogram exercise in ../exercises/isogram/IsogramTest.cs
[17:11:07 INF] Generated tests for kindergarten-garden exercise in ../exercises/kindergarten-garden/KindergartenGardenTest.cs
// Notice how the LargestSeriesProduct isn't generated 
// because the exercise generator doesn't exist yet.
[17:11:07 INF] Generated tests for leap exercise in ../exercises/leap/LeapTest.cs
.
.
.
[17:11:07 INF] Generated tests for saddle-points exercise in ../exercises/saddle-points/SaddlePointsTest.cs
.
.
.
[17:11:08 INF] Generated tests for wordy exercise in ../exercises/wordy/WordyTest.cs
[17:11:08 INF] Re-generated test classes.
~/D/P/e/c/generators (master) $ cd ..
~/D/P/e/csharp_checkout (master) $ git status
On branch master
Your branch is up-to-date with 'origin/master'.
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   exercises/complex-numbers/ComplexNumbersTest.cs
	modified:   exercises/isogram/IsogramTest.cs
	modified:   exercises/largest-series-product/Example.cs
	modified:   exercises/largest-series-product/LargestSeriesProductTest.cs
	modified:   exercises/saddle-points/SaddlePointsTest.cs

no changes added to commit (use "git add" and/or "git commit -a")
~/D/P/e/csharp_checkout (master) $ 
file exercises/largest-series-product/LargestSeriesProductTest.cs 
exercises/largest-series-product/LargestSeriesProductTest.cs: ASCII text, with very long lines, with CRLF line terminators
~/D/P/e/csharp_checkout (master) $ file exercises/largest-series-product/Example.cs 
exercises/largest-series-product/Example.cs: ASCII text, with CRLF line terminators
~/D/P/e/csharp_checkout (master) $ 
file exercises/complex-numbers/ComplexNumbersTest.cs 
exercises/complex-numbers/ComplexNumbersTest.cs: ASCII text, with CRLF, LF line terminators
~/D/P/e/csharp_checkout (master) $ file exercises/isogram/IsogramTest.cs 
exercises/isogram/IsogramTest.cs: ASCII text
~/D/P/e/csharp_checkout (master) $ file exercises/saddle-points/SaddlePointsTest.cs 
exercises/saddle-points/SaddlePointsTest.cs: ASCII text, with CRLF, LF line terminators

As you can see, the tests are generated weirdly. We have a variety of line endings:

• ComplexNumbersTest.cs gets generated with a mix of CRLF and LF terminators
• IsogramTest.cs has only LF terminators
• And SaddlePointsTest.cs has a mix of CRLF and LF, just like ComplexNumbersTest.cs does.

Also, have in mind that the LargestProduct files only have CRLF endings. They don't have a mix. Therefore I'm guessing the problem behind it is different from the problem on the files that get generated:

• The generated files, as Erik says, should use the Environment.Newline ending. In this case, some of the values seem to be hardcoded and some aren't, and we end up with a mix of line endings.
• The default files, in this case the LargestProduct ones, must've been created with a CRLF and somehow that got saved into the repository. I have no idea how, if as @jpreese said, Windows users work with CRLF without usually propagating it to the Unix users' repos thanks to the .gitattributes file.

[robkeim]

If we want to squash this problem once and for all (normalizing on \n) this is what we need to do:

1. Update .gitattributes to force eol=lf for *.cs, *.csproj, *.sln (maybe we could just add a rule for *)
2. Update generators to use \n instead of Environment.Newline (this may not be strictly necessary because git would overwrite the changes when it does it's normalization)
3. Re-run the test generators
4. Do a find/replace in all of the current code base for \r\n to \n
5. Send a PR/checkin

Does that seem reasonable?

[jpreese]

@robkeim I agree with the approach, though I'm still lost on how it only impacts a select few. @ErikSchierboom wasn't able to reproduce on his Mac, which doesn't use CRLF either.

Have we pinpointed the source of the problem? I'd love to be able to reproduce it on my end. Even if I need to spin up a docker container if this only is a linux problem.

[ErikSchierboom]

The default files, in this case the LargestProduct ones, must've been created with a CRLF and somehow that got saved into the repository.

Well that's an easy question, as we haven't always had a .gitattributes file :)

I like the approach by @robkeim, but perhaps we can do one other modification. We can use the steps proposed to normalize all the line-endings in the Git repository. However, once that is committed I would then like to see if changing the line-ending format back to auto (assuming we use Environment.Newline then) fixes the issue. Does that make sense?

The first step will thus be to normalize the line-endings in Git. The following document might help: https://help.github.com/articles/dealing-with-line-endings/#refreshing-a-repository-after-changing-line-endings

[GKotfis]

Another document about that problem: You're just another carriage return line feed in the wall
I also was confused about which approach should I use. But I think we should normalize repo and switch to Environment.NewLine

[jpreese]

FWIW the linked article actually has the LF normalization approach crossed out.

I'm still a little lost on exactly what the problem is. Bits and pieces make sense, but there's some details that seem unclear.

• Right now our entire repository is CRLF. So this shouldn't ever be a problem for Windows users.

• If you're on a Linux machine, these CRLFs should be made LF, similar to what @ErikSchierboom said. CRLF for Windows, LF for Linux.

How is @felix91gr getting CRLF on a Linux machine without even running the generators?

I can see how this can be problematic when forcing \r\n in a generator. The generator is adding the \r\n whereas if the user on a Linux box were to do that, it would only be \n. So text=auto is trying to change it to LF.

Which kind of leads to my next question, if I understand how gitattribute works, if we're on a Windows machine with * text=auto, does Git actually store the files as LF? And when we check these files out in Windows they are made into CRLF, only for our machines.

[ErikSchierboom]

I have no idea how to check that.

[jpreese]

When I get some time, I'm going to try and spin up a Linux container and see if I can reproduce this. Though it's a little strange that it doesn't break on your Mac either.

[felix91gr]

Regarding files that are problematic before running the generator

(Erik's)

Well that's an easy question, as we haven't always had a .gitattributes file :)

Yes! That seems to be exactly what's happenning. Check this out:

So, at least those files should be able to be changed such that they are normalized automatically to LF in Unix and CRLF in WIndows, without git going crazy.

I guess that answers @jpreese's question :)

Other things

(jpreese's)

I'd love to be able to reproduce it on my end. Even if I need to spin up a docker container if this only is a linux problem.

Please do! Even if it's unlikely that my setup has a unique bug (I'm using an almost pure Ubuntu derivative), we should be trying to reproduce this on as many machines as possible to, as you say, pinpoint the source.

Though it's a little strange that it doesn't break on your Mac either.

Yeah... weird. But Macs are sometimes magical like that. Or maybe just a Mac user saw this problem a long time ago and made a PR to the Mac branch of git to sort of fix the problem

Regarding the files generated with CRLF after using dotnet run

(Erik's)

I like the approach by @robkeim, but perhaps we can do one other modification. We can use the steps proposed to normalize all the line-endings in the Git repository. However, once that is committed I would then like to see if changing the line-ending format back to auto (assuming we use Environment.Newline then) fixes the issue. Does that make sense?

I agree with this approach. As soon as I get some more time, I'll read all the articles everyone has posted. There must be some clues as to what's going on under the hood.

[felix91gr]

@jpreese, have you downloaded the latest commit of this PR? Maybe we could check if Windows's git normalizes the line endings to CRLF, while at the same time not saying the following files have uncommited changes. That would surely mean that they were fixed.

[jpreese]

So, on a windows machine, when you commit, does gitattributes turn all CRLF's into LF? That makes a little more sense where the commit hash contains changes to the file in LF format.. but before the time of gitattributes, it was committed as CRLF?

I guess I'm just stuck on the fact that right now LargestSeriesProduct is CRLF (as is everything else).. so when @felix91gr pulls this down, his line endings should be changed to LF anyway. Why is this one file special.

[felix91gr]

Why is this one file special.

Our guess is that it's because those two files were created before the .gitattributes file. Therefore, the normalization changes to the "true copy" stored in the repo haven't happened yet. If and when they get changed and commited, they should be affected by the normalization.

If this hypothesis is true, two things should be happenning:

1. When you download this PR's commit, you should see them ending with CRLF, and your git shouldn't complain.
2. When I download this PR's commit, I should see them ending with LF, and my git shouldn't complain, unlike it does atm.

Wanna check? :)

[felix91gr]

Test results

Normalization worked here :)

git clone https://github.com/felix91gr/csharp csharp_check_LF
Cloning into 'csharp_check_LF'...
remote: Counting objects: 4981, done.
remote: Compressing objects: 100% (12/12), done.
remote: Total 4981 (delta 4), reused 10 (delta 4), pack-reused 4965
Receiving objects: 100% (4981/4981), 1.67 MiB | 857.00 KiB/s, done.
Resolving deltas: 100% (3022/3022), done.
Checking connectivity... done.
~/D/P/exercism $ cd csharp_check_LF
~/D/P/e/csharp_check_LF (master) $ git checkout fix-line-endings-1-commit 
Branch fix-line-endings-1-commit set up to track remote branch fix-line-endings-1-commit from origin.
Switched to a new branch 'fix-line-endings-1-commit'
~/D/P/e/csharp_check_LF (fix-line-endings-1-commit) $ git status
// No complains! YES!
On branch fix-line-endings-1-commit
Your branch is up-to-date with 'origin/fix-line-endings-1-commit'.
nothing to commit, working directory clean
~/D/P/e/csharp_check_LF (fix-line-endings-1-commit) $ 
file exercises/largest-series-product/LargestSeriesProductTest.cs 
// No CRLF! :D
exercises/largest-series-product/LargestSeriesProductTest.cs: ASCII text, with very long lines
~/D/P/e/csharp_check_LF (fix-line-endings-1-commit) $ 
file exercises/largest-series-product/Example.cs 
// No CRLF either! :)
exercises/largest-series-product/Example.cs: ASCII text 

If point (1.) works on your computer @jpreese, then we've solved the mystery for the largest-series-product files

[jpreese]

Ok so if you checkout the master branch, you see LF in all of the files except for the largest series exercise right? You see CRLF?

[felix91gr]

You see CRLF?

Yup! In exercism's master, in the largest-product-series directory, only those two files have CRLF.

Ok so if you checkout the master branch, you see LF in all of the files except for the largest series exercise right?

Yes, as far as I can test without running over all of the files one by one. My git seems happy with all of the files except for those two, when I checkout master.

EDIT

Well, also the .sln files and .ps1 files have CRLF endings. The .gitattributes file seems to be doing what's in the tin for those two. My git is happy with them, they give no problem.

[jpreese]

When you say "git seems happy", that means that the files that you have checked, use strictly LF?

[felix91gr]

When you say "git seems happy", that means that the files that you have checked, use strictly LF?

No... what I mean by that is that git doesn’t complain. When I invoke git status after a checkout, it should say “working directory clean, no changes to commit”.

A checkout of master introduces changes in those two files without me doing anything. And I can’t cancel those changes either.

A checkout of this branch however, doesn’t trigger those changes. And it also leaves me with LF endings where they should be.

If this change is good, it should be similar for you:

• No git complaints (“sir you changed this and that” after a checkout)
• CRLF in the files (as it should be, because you’re in Windows)

[ErikSchierboom]

Okay, so if I understand correctly, this PR the issues?

[jpreese]

It should, yeah. I just really don't see how the timing of a gitattributes file impacts these files. Before the gitattributes, this file and all of the other files had CRLF. When you introduce gitattributes, it still has that CRLF. Windows users commit as CRLF, Linux users commit as LF. But the endings need to be stored on orgin in one of those (unless it just flips back and forth the gitattributes ignores the line endings so it doesn't show up in the diff?).

Theres just some processes happening on the back end that I'm missing. I'll probably just have to spend some time playing with different OS's and commits with gitattributes, I personally still don't quite understand how this is occuring in the first place.

[felix91gr]

@jpreese I know what you mean. Git is kind of a mess... Linus Torvalds laughed at SVN, saying he programmed git in two weeks and still managed to kick their ass. But such speed comes with a lot of “magic” like this and bad ergonomics like the gitless researchers have explored.

I have no answer as to why this is happenning. But maybe we can fix it... try this PR and tell me what you see :)

[jpreese]

Yeah, it fixes it. But I'm a stickler for knowing why its a problem in the first place. I'm not saying we can't merge it, I just need to figure out the source of the problem.

[jpreese]

I just ran this on on a Linux container and the working directory was free of CRLF issues.. what Linux distro are you using?

[felix91gr]

Oh, shit dawg! Good thing you tested it.

Then there must be something weird in my setup, let's see:

• Linux distro: Elementary OS Loki
• git --version output: git version 2.7.4.
  This is what I get when I run your commands:

~ $ cat /etc/*-release
DISTRIB_ID="elementary"
DISTRIB_RELEASE=0.4.1
DISTRIB_CODENAME=loki
DISTRIB_DESCRIPTION="elementary OS 0.4.1 Loki"
NAME="elementary OS"
VERSION="0.4.1 Loki"
ID="elementary"
ID_LIKE=ubuntu
PRETTY_NAME="elementary OS 0.4.1 Loki"
VERSION_ID="0.4.1"
HOME_URL="http://elementary.io/"
SUPPORT_URL="http://elementary.io/support/"
BUG_REPORT_URL="https://github.com/elementary/"
VERSION_CODENAME=loki
UBUNTU_CODENAME=loki
cat: /etc/upstream-release: Is a directory

[felix91gr]

Now that I’ve looked it up, the latest git is 2.14. Shhhhhhhhhhhhhhhhhhit. I have the 2.7.4! XD that’s probably the problem.

Which one do you have?

[jpreese]

Ok so, using your distrobution with Git 2.7.4 I do get the same results

HOWEVER. If you install the latest version of Git, the warning goes away.

sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get install git

[jpreese]

So assuming that fixes it for you, this makes a lot more sense to me. I still have no idea why that version of git was picky. I could try downgrading my Git on my Ubuntu container down to 2.7.4 and see if it errors there, but at least its a Git version thing.

What I was trying to say above is that your situation just didn't make any sense at all. @ErikSchierboom couldn't replicate, I couldn't replicate, even on a Linux box. So it must be with how old versions of Git handles .gitattributes

[felix91gr]

You did it, man. You found the answer. And now...

rm -rf csharp_clean/
~/D/P/exercism $ git clone https://github.com/exercism/csharp/ csharp_clean
Cloning into 'csharp_clean'...
remote: Counting objects: 4990, done.
remote: Compressing objects: 100% (34/34), done.
remote: Total 4990 (delta 15), reused 27 (delta 9), pack-reused 4947
Receiving objects: 100% (4990/4990), 1.67 MiB | 1.85 MiB/s, done.
Resolving deltas: 100% (3021/3021), done.
~/D/P/exercism $ cd csharp_clean
~/D/P/e/csharp_clean (master) $ git status
On branch master
Your branch is up-to-date with 'origin/master'.

nothing to commit, working tree clean

git is happy :3

[felix91gr]

So, whatever with this PR? Or should we merge it?

[jpreese]

Thats using Debian with version 2.7.4, same issue. So I'm inclined to believe that they did something after version 2.7.4

[felix91gr]

Yup, indeed.

What we have left is to check the generated files, because maybe there’s an issue there (with the Environment.Newline or something).

But the issue with the preexisting files is no more :3 thanks, jp!

(I’ll be back tomorrow. Night!’)

[ErikSchierboom]

Great research work!

[jpreese]

Yeah my next step is to see what changed between the versions. Again, to me, I'm curious how gitattributes knows that the LargestSeries file was added before it. I'm curious if gitattributes does something to the commit hash, so it knows that it should transform it. So LargestSeries is a problem because it was added before gitattributes and doesn't have that special something. I don't know how else gitattributes would know about it. This is all me talking aloud 🤣

Though I'm pretty sure there are more files than just those two that were added before gitattributes, unless they've just been updated over time. Who knows.

[felix91gr]

doesn't have that special something. I don't know how else gitattributes would know about it. This is all me talking aloud 🤣

I know right? Go home git, you’re drunk 😆

Though I'm pretty sure there are more files than just those two that were added before gitattributes, unless they've just been updated over time. Who knows.

There are no more in that directory, I’ve checked them. But maybe there are in the other folders. Do you know of a quick way to check which files were last modified before a certain date? There are too many to be checking by hand :v

[robkeim]

Good detective work tracking this down @felix91gr and @jpreese!

@felix91gr this should give you a list of the last modification date for all of the files:
https://serverfault.com/questions/401437/how-to-retrieve-the-last-modification-date-of-all-files-in-a-git-repository

The output format seems to be already sorted by date so that should give you what you're looking for.

[felix91gr]

Thank you, @robkeim!

Using that script + regexes, I made this list of files that were last modified before or at the same time than .gitattributes:

.gitattributes
bin/fetch-configlet
docs/LEARNING.md
exercises/accumulate/Accumulate.cs
exercises/accumulate/AccumulateTest.cs
exercises/accumulate/Example.cs
exercises/acronym/Acronym.cs
exercises/acronym/Example.cs
exercises/alphametics/Alphametics.cs
exercises/alphametics/Example.cs
exercises/alphametics/HINTS.md
exercises/atbash-cipher/AtbashCipher.cs
exercises/atbash-cipher/Example.cs
exercises/bank-account/BankAccount.cs
exercises/bank-account/BankAccountTest.cs
exercises/bank-account/Example.cs
exercises/bank-account/HINTS.md
exercises/beer-song/HINTS.md
exercises/binary-search-tree/BinarySearchTree.cs
exercises/binary-search-tree/BinarySearchTreeTest.cs
exercises/binary-search-tree/Example.cs
exercises/bowling/Bowling.cs
exercises/bowling/BowlingTest.cs
exercises/bowling/Example.cs
exercises/change/Change.cs
exercises/change/ChangeTest.cs
exercises/change/Example.cs
exercises/circular-buffer/CircularBuffer.cs
exercises/circular-buffer/CircularBufferTest.cs
exercises/circular-buffer/Example.cs
exercises/clock/HINTS.md
exercises/connect/Connect.cs
exercises/connect/ConnectTest.cs
exercises/connect/Example.cs
exercises/custom-set/CustomSet.cs
exercises/custom-set/CustomSetTest.cs
exercises/custom-set/Example.cs
exercises/custom-set/HINTS.md
exercises/difference-of-squares/DifferenceOfSquares.cs
exercises/difference-of-squares/DifferenceOfSquaresTest.cs
exercises/difference-of-squares/Example.cs
exercises/difference-of-squares/HINTS.md
exercises/diffie-hellman/DiffieHellman.cs
exercises/diffie-hellman/DiffieHellmanTest.cs
exercises/diffie-hellman/Example.cs
exercises/diffie-hellman/HINTS.md
exercises/dominoes/Dominoes.cs
exercises/dominoes/DominoesTest.cs
exercises/dominoes/Example.cs
exercises/dot-dsl/DotDsl.cs
exercises/dot-dsl/DotDslTest.cs
exercises/dot-dsl/Example.cs
exercises/dot-dsl/HINTS.md
exercises/error-handling/ErrorHandling.cs
exercises/error-handling/ErrorHandlingTest.cs
exercises/error-handling/Example.cs
exercises/flatten-array/Example.cs
exercises/flatten-array/FlattenArray.cs
exercises/flatten-array/FlattenArrayTest.cs
exercises/food-chain/HINTS.md
exercises/forth/Example.cs
exercises/forth/Forth.cs
exercises/forth/ForthTest.cs
exercises/forth/HINTS.md
exercises/go-counting/Example.cs
exercises/go-counting/GoCounting.cs
exercises/go-counting/GoCountingTest.cs
exercises/grains/Grains.cs
exercises/grep/Example.cs
exercises/grep/Grep.cs
exercises/grep/GrepTest.cs
exercises/hangman/Example.cs
exercises/hangman/HINTS.md
exercises/hangman/Hangman.cs
exercises/hangman/HangmanTest.cs
exercises/hello-world/Example.cs
exercises/hello-world/HelloWorld.cs
exercises/isogram/Example.cs
exercises/isogram/Isogram.cs
exercises/largest-series-product/Example.cs
exercises/largest-series-product/LargestSeriesProduct.cs
exercises/largest-series-product/LargestSeriesProductTest.cs
exercises/leap/Example.cs
exercises/leap/Leap.cs
exercises/ledger/Example.cs
exercises/ledger/Ledger.cs
exercises/ledger/LedgerTest.cs
exercises/linked-list/Example.cs
exercises/linked-list/LinkedList.cs
exercises/linked-list/LinkedListTest.cs
exercises/list-ops/Example.cs
exercises/list-ops/ListOps.cs
exercises/list-ops/ListOpsTest.cs
exercises/luhn/Example.cs
exercises/luhn/Luhn.cs
exercises/markdown/Example.cs
exercises/markdown/HINTS.md
exercises/markdown/Markdown.cs
exercises/markdown/MarkdownTest.cs
exercises/matrix/Example.cs
exercises/matrix/Matrix.cs
exercises/matrix/MatrixTest.cs
exercises/meetup/Example.cs
exercises/meetup/Meetup.cs
exercises/meetup/MeetupTest.cs
exercises/minesweeper/Example.cs
exercises/minesweeper/Minesweeper.cs
exercises/minesweeper/MinesweeperTest.cs
exercises/nth-prime/Example.cs
exercises/nth-prime/HINTS.md
exercises/nth-prime/NthPrime.cs
exercises/ocr-numbers/OcrNumbers.cs
exercises/palindrome-products/Example.cs
exercises/palindrome-products/PalindromeProducts.cs
exercises/palindrome-products/PalindromeTest.cs
exercises/pangram/Example.cs
exercises/pangram/Pangram.cs
exercises/parallel-letter-frequency/Example.cs
exercises/parallel-letter-frequency/ParallelLetterFrequency.cs
exercises/parallel-letter-frequency/ParallelLetterFrequencyTest.cs
exercises/perfect-numbers/Example.cs
exercises/perfect-numbers/PerfectNumbers.cs
exercises/pig-latin/PigLatin.cs
exercises/poker/Poker.cs
exercises/pov/Example.cs
exercises/pov/Pov.cs
exercises/pov/PovTest.cs
exercises/protein-translation/Example.cs
exercises/protein-translation/ProteinTranslation.cs
exercises/protein-translation/ProteinTranslationTest.cs
exercises/proverb/Example.cs
exercises/proverb/HINTS.md
exercises/proverb/Proverb.cs
exercises/proverb/ProverbTest.cs
exercises/pythagorean-triplet/Example.cs
exercises/pythagorean-triplet/PythagoreanTriplet.cs
exercises/pythagorean-triplet/PythagoreanTripletTest.cs
exercises/rail-fence-cipher/Example.cs
exercises/rail-fence-cipher/RailFenceCipher.cs
exercises/raindrops/Example.cs
exercises/raindrops/Raindrops.cs
exercises/react/Example.cs
exercises/react/HINTS.md
exercises/react/React.cs
exercises/react/ReactTest.cs
exercises/rectangles/Example.cs
exercises/rectangles/Rectangles.cs
exercises/rectangles/RectanglesTest.cs
exercises/robot-name/Example.cs
exercises/robot-name/RobotName.cs
exercises/robot-name/RobotNameTest.cs
exercises/robot-simulator/Example.cs
exercises/robot-simulator/RobotSimulator.cs
exercises/robot-simulator/RobotSimulatorTest.cs
exercises/roman-numerals/Example.cs
exercises/roman-numerals/HINTS.md
exercises/roman-numerals/RomanNumerals.cs
exercises/run-length-encoding/Example.cs
exercises/run-length-encoding/RunLengthEncoding.cs
exercises/saddle-points/Example.cs
exercises/saddle-points/SaddlePoints.cs
exercises/say/Example.cs
exercises/say/Say.cs
exercises/scale-generator/Example.cs
exercises/scale-generator/ScaleGenerator.cs
exercises/scale-generator/ScaleGeneratorTest.cs
exercises/secret-handshake/Example.cs
exercises/series/Example.cs
exercises/series/Series.cs
exercises/series/SeriesTest.cs
exercises/sgf-parsing/Example.cs
exercises/sgf-parsing/HINTS.md
exercises/sgf-parsing/SgfParsing.cs
exercises/sgf-parsing/SgfParsingTest.cs
exercises/sieve/Sieve.cs
exercises/simple-cipher/Example.cs
exercises/simple-cipher/SimpleCipher.cs
exercises/simple-cipher/SimpleCipherTest.cs
exercises/simple-linked-list/Example.cs
exercises/simple-linked-list/HINTS.md
exercises/simple-linked-list/SimpleLinkedList.cs
exercises/simple-linked-list/SimpleLinkedListTest.cs
exercises/space-age/Example.cs
exercises/space-age/SpaceAge.cs
exercises/strain/Example.cs
exercises/strain/Strain.cs
exercises/strain/StrainTest.cs
exercises/sublist/Example.cs
exercises/sublist/HINTS.md
exercises/sublist/Sublist.cs
exercises/sublist/SublistTest.cs
exercises/tournament/Tournament.cs
exercises/transpose/Transpose.cs
exercises/tree-building/Example.cs
exercises/tree-building/TreeBuilding.cs
exercises/tree-building/TreeBuildingTest.cs
exercises/twelve-days/Example.cs
exercises/twelve-days/HINTS.md
exercises/twelve-days/TwelveDays.cs
exercises/twelve-days/TwelveDaysTest.cs
exercises/variable-length-quantity/Example.cs
exercises/variable-length-quantity/HINTS.md
exercises/variable-length-quantity/VariableLengthQuantity.cs
exercises/variable-length-quantity/VariableLengthQuantityTest.cs
exercises/word-search/Example.cs
exercises/word-search/HINTS.md
exercises/word-search/WordSearch.cs
exercises/word-search/WordSearchTest.cs
exercises/wordy/HINTS.md
exercises/zebra-puzzle/Example.cs
exercises/zebra-puzzle/ZebraPuzzle.cs
exercises/zebra-puzzle/ZebraPuzzleTest.cs
exercises/zipper/Example.cs
exercises/zipper/Zipper.cs
exercises/zipper/ZipperTest.cs
generators/Generators.sln
generators/generate.ps1
generators/generate.sh
img/icon.png

Now I'm gonna loop over them and see what file has to say about them.

[felix91gr]

Final verdict on old files

Looping over all of the files that preceded .gitattributes, and checking whether or not they had CRLF line endings, we get the following:

exercises/largest-series-product/Example.cs: ASCII text, with CRLF line terminators
exercises/largest-series-product/LargestSeriesProductTest.cs: ASCII text, with very long lines, with CRLF line terminators
generators/Generators.sln: UTF-8 Unicode (with BOM) text, with CRLF line terminators
generators/generate.ps1: ASCII text, with CRLF line terminators

And those are all of them.

So, @jpreese: the error appears to occur only if:

• The file is older than .gitattributes.
• The file has CRLF endings and its extension isn't mentioned in .gitattributes as having CRLF by default.

Do you agree with me?
The other option would be that the date of creation of .gitattributes doesn't matter, but that would be very strange, because then... why the coincidence? And I feel there might be another contradiction that stems from that, that I'm missing. It would really kind of shock me 🤔

[jpreese]

Yeah, if you wanted to dig some more that'd be great. I won't be able to check it out till later. I'm curious if the date that gitattributes was added matters. There's just too much of a coincidence.

[jpreese]

After the above investigations, this should be resolved with newer versions of Git. I'd prefer to just stay with auto.

[felix91gr]

👍🏻

…

On Mon, Oct 9, 2017 at 10:12 PM John Reese ***@***.***> wrote: Closed #461 <#461>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#461 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALNBJ4RV9TdmQT5idESueQVUYPD4pmsbks5sqsR6gaJpZM4PuhSs> .