Mintty/Git somehow newlines turned into ^M

413 views
Skip to first unread message

skybuck2000

unread,
Dec 29, 2021, 1:54:25 AM12/29/21
to git-for-windows
I AM VERY PISSED OFF ABOUT THIS...

Code that was like:

Begin

End

Is now
Begin
End

White lines are disappearing after sticks together !

HOW THE FUCK DID THIS HAPPEN ?!?!?!?

Was it buggy Minnty ?!

Was it buggy Delphi ?!

Was it buggy Git ?!

Was it Textpad ?!

Was it accidently settings switch ?!?

Was it ansi encoding ?

Will unicode encoding help ?!?!?

Holy fucking shit.

Can't even program decently or compare or commit decently because of this shitty ^M new line problem...

HOLYSHIT.

Also mintty cannot display paths with spaces in it.

Also mintty cannot tab to folders like cmd.exe can.

I AM CONSIDERING DUMPING LINUX AND MINTTY FOREVER.

CANNOT DEAL WITH THIS LITTLE ENDIAN BIG ENDIAN NONENSE.

OR WHERE TO START EATING EGGS.

WINDOWS IS MAIN DESKTOP OPERATING SYSTEM FOR EVERYTHING

LINUX FUCKS ON THE SERVER.

LINUX NEEDS TO ADEPT TO WINDOWS AND FOLLOW WINDOWS LEAD
WHEN IT COMES TO NEW LINES AND SHIT.

GIVE ME ONE GOOD REASON WHY IT SHOULD NOT.

Bye,
  Skybuck.

skybuck2000

unread,
Dec 29, 2021, 2:30:52 AM12/29/21
to git-for-windows
A futher problem with this is if git uses some different symbol for newline then git will see the entire file as deleted.

Anyway reading up on newlines:



HOW THE FUCK IS GIT NOT WORKING, IT SAYS LF...

even if CR LF is there... why does it think it's a single line ?! 

Something is fucked up:


^ This is creating GIT DIFF difficulties and tracking/history and merge difficulties for sure...

Perhaps replacing CR LF in all files in git repository may help, but that would rewrite the whole damn thing and lost commit hashes and whatever...

I also tried denormalize but that is retarded apperently... I think this is actually the function for it, but that loses changes ?!?!?

WHACKY STUFF.

Also a programmer friendly encoding standard would have my preference then this shit.
a to z
0 to 9
symbols on keyboard
new line terminator
tab character
THAT IS IT, shove the rest ! =D

Bye for now,
  Skybuck.

skybuck2000

unread,
Dec 29, 2021, 2:35:05 AM12/29/21
to git-for-windows
THIS FILE FUCKED UP SOMEHOW ?!?!?!?:

Input/gui-classic/UFRMWallet.pas

I need way to restore it some it diffs properly.

I kinda don't want to re-do the entire thing it might not be necessary if all it is is a line end problem.

I think I may have also tried to correct it in Delphi editor cause at first I thought it is Delphi editor problem...

Not sure what caused it Delphi 10.4 buggy as motherfucking hell in all kinds of windows fucking annoying.

Could also be a windows 11 fuck up..

I have no idea what caused this..


Change some setting from auto crlf from false to true after this problemn started occuring maybe that will prevent this in future but I will read up on it anyway..

I need a couple of things:

1. I want to know how many times these weird line endings happen in this repositorry or any repo.

2. Need a way to convert this stuff... or not if that is not good for history.

3. editor that can display these control characters... delphi needs update for this hopefully in future...

Textpad also can't do it properly... both editors completely fail to shine light on this fucking sucks.

Bye for now,
  Skybuck.

skybuck2000

unread,
Dec 29, 2021, 2:35:47 AM12/29/21
to git-for-windows

why the fuck is google bitching up my github link ogh mty god stop interfering assholhes at google.

STICK YOYUR FCUKIG NANJOYING POP UP UO YOUR AQSSS
IT S NOT A FUCKING E-MAILK FGUCKIONG IDIOT SOFTWARE.

skybuck2000

unread,
Dec 29, 2021, 2:36:46 AM12/29/21
to git-for-windows
google test:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

^ this is not a fucking e-mail address

BYE

skybuck2000

unread,
Dec 29, 2021, 2:36:57 AM12/29/21
to git-for-windows
rsghasdgkjasdhgjkasdhgjh@sdfgkjsdfkghjsdfghd

skybuck2000

unread,
Dec 29, 2021, 2:37:08 AM12/29/21
to git-for-windows
LOL YOU FAIL GOOGLE.

skybuck2000

unread,
Dec 29, 2021, 2:37:18 AM12/29/21
to git-for-windows
DFgsdbghsdfg@asdfxgsdfghdf@

skybuck2000

unread,
Dec 29, 2021, 2:37:56 AM12/29/21
to git-for-windows
since wqhen do e-mail addresses have two @sdgdfgdf@

skybuck2000

unread,
Dec 29, 2021, 2:38:06 AM12/29/21
to git-for-windows
sdfgseagsdgds@sdfgsdgsd@dsfgsdfgdsfg

skybuck2000

unread,
Dec 29, 2021, 2:38:40 AM12/29/21
to git-for-windows
great now I can't even post sdgsdfg@s@dxfgsdfga@edfasdsdfgdsfgd@ g
 without google buggy me about e-mail addresses fucking fantastic !

skybuck2000

unread,
Dec 29, 2021, 2:40:30 AM12/29/21
to git-for-windows
NOW YOU KNOW WHY I HATE PARSERS....


EVEBODY THAT USES HTML, XML, JSON AND ALL THAT OTHER CRAP


FUCK ALL YOU IMBECILS.

STICK WITH BINARY FORMATS.

FOR ASCII AND ANSCI AND UNICODE I WILL MAKE AN EXCEPTION

BUT OH BOY DID YOU FUCKING MORONS FUCK THAT UP TOO.



BYE, BYE,
  SKYBUCK LOL.

skybuck2000

unread,
Dec 29, 2021, 2:43:32 AM12/29/21
to git-for-windows
A POSSIBLE SOLUTION TO DUMP ASCII, ANSI,UNICODE, EBCDIC AND ALL THAT OTHER GARBAGE FOREVER IS INDEED A BINARY FORMAT THAT ACTUALLY MAKES SENSE AND CANNOT BE MIS INTERPRETED:

NEW BINARY FORMAT FOR TEXT:

TEXT HEADER STRUCTURE
ARRAY OF END OF LINE POSITIONS.
TEXT HEADER STRUCTURE

TEXT DATA
CHARACTERS
TEXT DATA

THERE SOLVED THATR PROBLENM FOR YOU BUNCH OF FUCKING IDIOTS.\

\HAHAHAHAHAHAHAH

NOW YOU NEED A DYNAMIC ARRAY OR SOME OTHER GROWING STRUCTURE

ISN THAT TOO THOUGH FOR YOU GET HTE FUCK OUT./

BYE, 
  SKYBUCK LOLOLOL.

skybuck2000

unread,
Dec 29, 2021, 3:09:29 AM12/29/21
to git-for-windows
Anyway if you have ever used a typing machine than you know it does this:


rgsdgsdfgsdfghsdfhsdhfghd->>>>

<------------------------- CARRIAGE RETURN ?
\/ LINE FEED ?!?!

^ Probably this.

So windows is RIGHT, and the rest that uses it TOO.

And linux is just STUPID and too efficient orwhatever.. and GIT is stupid too.

Imagine having to print this on an old printer with only line feed it might go BAD> :P*

I will laugh at you BYE

Bye for now,
  Skybuck.


skybuck2000

unread,
Dec 29, 2021, 3:33:07 AM12/29/21
to git-for-windows

This explains it best:

linux - git replacing LF with CRLF - Stack Overflow

Updated my "batch file":

echo Step 9 configure line endings for Microsoft Windows Operating Systems
echo Step 9 (convert CRLF to LF on commit) and (LF to CRLF on checkouts)
git config --global core.autocrlf true


These messages are due to incorrect default value of core.autocrlf on Windows.

The concept of autocrlf is to handle line endings conversions transparently. And it does!

Bad news: value needs to be configured manually.
Good news: it should only be done ONE time per git installation (per project setting is also possible).

How autocrlf works:

core.autocrlf=true: core.autocrlf=input: core.autocrlf=false: 
 repo repo repo 
 ^ V ^ V ^ V 
 / \ / \ / \
 crlf->lf lf->crlf crlf->lf 
 \ / \ / \ / \ / \

^ ascci picture fucked up, ain't the web great ?! ;)
 

Here crlf = win-style end-of-line marker, lf = unix-style (and mac osx).

(pre-osx cr in not affected for any of three options above)

When does this warning show up (under Windows)

    – autocrlf = true if you have unix-style lf in one of your files (= RARELY),
    – autocrlf = input if you have win-style crlf in one of your files (= almost ALWAYS),
    – autocrlf = false – NEVER!

What does this warning mean

The warning "LF will be replaced by CRLF" says that you (having autocrlf=true) will lose your unix-style LF after commit-checkout cycle (it will be replaced by windows-style CRLF). Git doesn't expect you to use unix-style LF under windows.

The warning "CRLF will be replaced by LF" says that you (having autocrlf=input) will lose your windows-style CRLF after a commit-checkout cycle (it will be replaced by unix-style LF). Don't use input under windows.

Yet another way to show how autocrlf works

1) true: x -> LF -> CRLF 2) input: x -> LF -> LF 3) false: x -> x -> x

where x is either CRLF (windows-style) or LF (unix-style) and arrows stand for

file to commit -> repository -> checked out file

How to fix

Default value for core.autocrlf is selected during git installation and stored in system-wide gitconfig (%ProgramFiles(x86)%\git\etc\gitconfig on windows, /etc/gitconfig on linux). Also there're (cascading in the following order):

   – "global" (per-user) gitconfig located at ~/.gitconfig, yet another
   – "global" (per-user) gitconfig at $XDG_CONFIG_HOME/git/config or $HOME/.config/git/config and
   – "local" (per-repo) gitconfig at .git/config in the working dir.

So, write git config core.autocrlf in the working dir to check the currently used value and

   – git config --system core.autocrlf false            # per-system solution
   – git config --global core.autocrlf false            # per-user solution
   – git config --local core.autocrlf false              # per-project solution

Warnings
– git config settings can be overridden by gitattributes settings.
– crlf -> lf conversion only happens when adding new files, crlf files already existing in the repo aren't affected.

Moral (for Windows):
    - use core.autocrlf = true if you plan to use this project under Unix as well (and unwilling to configure your editor/IDE to use unix line endings),
    - use core.autocrlf = false if you plan to use this project under Windows only (or you have configured your editor/IDE to use unix line endings),
    - never use core.autocrlf = input unless you have a good reason to (eg if you're using unix utilities under windows or if you run into makefiles issues),

PS What to choose when installing git for Windows?
If you're not going to use any of your projects under Unix, don't agree with the default first option. Choose the third one (Checkout as-is, commit as-is). You won't see this message. Ever.

PPS My personal preference is configuring the editor/IDE to use Unix-style endings, and setting core.autocrlf to false.

Reply all
Reply to author
Forward
0 new messages