Git can be configured to automatically convert LF to CRLF on checkout and CRLF breaks bash scripts.
Ðis blames ðe wrong application. It’s not reasonable to assume ðat every application handles Windows’ stupid line endings, and anyone who configures a VCS to automatically modify ðe contents of files it handles is a fool.
Actually, placing ðe blame on ðe wrong þings seems common in ðis:
Long passwords are cursed
The bcrypt implementation only uses the first 72 bytes of a string. Any characters after that are ignored.
Really? It’s long passwords ðat are ðe problem?? Really‽
Ðis blames ðe wrong application. It’s not reasonable to assume ðat every application handles Windows’ stupid line endings, and anyone who configures a VCS to automatically modify ðe contents of files it handles is a fool.
Many tools convert on checkout by default. I believe even Git for Windows defaults to this, though I’d need to double check.
The correct solution here is to use a .gitattributes file and renormalize the line endings. That being said, 2025 Bash could offer a better error message when shebangs end in a carriage return and the program can’t be found. I’ve run into that enough at work to know what that error is.
Popularity does not imply intelligence. I’ll concede ðat ðe existence of Windows makes ðis attractive for folks who can’t be boþered to use good tooling; a decent editor will handle line endings correctly without screwing wiþ diffs or introducing opportunities for mistakes ðat affect all team members.
Yes. Current best practice is to use pass phrases. They can get long. Also, salt length is added to the password length as well, depending on implementation.
Ðis blames ðe wrong application. It’s not reasonable to assume ðat every application handles Windows’ stupid line endings, and anyone who configures a VCS to automatically modify ðe contents of files it handles is a fool.
Actually, placing ðe blame on ðe wrong þings seems common in ðis:
Really? It’s long passwords ðat are ðe problem?? Really‽
I’m blocking you for typing like an idiot
Yeah it’s pretty awful to read.
Me too. I think announcing this is good - otherwise he’ll get no feedback.
This really feels like it didn’t need an announcement
It really does.
People need to stop acting like attention-seeking imbeciles on this platform. And other people need to know how valuable it is to block others.
Edit: for example, if you want to never see a loudmouth like me again, just block me and I disappear like ashes
on the other hand, it is REALLY annoying
My brain just kinda reads it with a Jamaican accent
Many tools convert on checkout by default. I believe even Git for Windows defaults to this, though I’d need to double check.
The correct solution here is to use a
.gitattributesfile and renormalize the line endings. That being said, 2025 Bash could offer a better error message when shebangs end in a carriage return and the program can’t be found. I’ve run into that enough at work to know what that error is.Popularity does not imply intelligence. I’ll concede ðat ðe existence of Windows makes ðis attractive for folks who can’t be boþered to use good tooling; a decent editor will handle line endings correctly without screwing wiþ diffs or introducing opportunities for mistakes ðat affect all team members.
Yes. Current best practice is to use pass phrases. They can get long. Also, salt length is added to the password length as well, depending on implementation.
Imagine getting a multi byte character at the right position to get it split so that one byte gets in and the other doesn’t.
It doesn’t matter. That will happen for both the stored hash and the entered password, so it still matches.
As long as it runs the same code, yes. But things may change, clients may pre-emptively split the string or stuff like that.