Line endings (LF vs CRLF)

[mjomble]

I use Unix-style line endings (LF) in my projects even when working on them in Windows.
I have the Git setting core.autocrlf globally set to false to avoid Git changing them to CRLF at any point.

However, it seems like Fork is ignoring the Git setting and converting LF-s to CRLF-s whenever I use checkout.
Is it possible to avoid this?

PS. I really like the application. I've wanted to stop using SourceTree for years because of its various issues (authentication ones are the most annoying), but so far hadn't found anything that kept many of the UI features from SourceTree that I really liked.
Until I found Fork which seems to be exactly what I wanted :)
Unfortunately, this one issue is currently keeping me from using it.
Are there any plans to make Fork open source?

[DanPristupov]

I will add that to our todo list.
As for now open git terminal using the button on the toolbar in Fork and set git config --global core.autocrlf false. It should work.

Regarding opening the source: we are not sure about that yet. Not in the near future, at least.

[mjomble]

As for now open git terminal using the button on the toolbar in Fork and set git config --global core.autocrlf false. It should work.

My first reaction was "I already had it configured like that", but then I figured out why this would work :D

Some notes for anyone else who might stumble onto the same issue:

I already had core.autocrlf=false in my system-wide git conf (C:\ProgramData\Git\config) so this applied in most situations where I use git.

However, Fork has its own git config (%LOCALAPPDATA%\Fork\git\mingw64\etc\gitconfig) which sets core.autocrlf=true and overrides the system-wide config. Which is why Fork was the only app where line endings were getting messed up.

Running git config --global core.autocrlf false modified my user-specific config (C:\Users\%USERNAME%\.gitconfig) which overrides both the Fork config and the system-wide config.
So now it's working fine :)

PS. A good tip for troubleshooting git config is to use git config --list --show-origin to see where the different values come from.
The output of this command can differ by context.
For example, I see one set of values in the regular command prompt and a different set when opening the command prompt from the Fork toolbar.

[DanPristupov]

@mjomble just to avoid confusion, the system-wide should be git-instance-wide.

Since you have an installed git in your system, it uses its own local config.

The correct way should be to define config parameters globally which will be visible for any instances in the system.

However, Fork has its own git config (%LOCALAPPDATA%\Fork\git\mingw64\etc\gitconfig) which sets core.autocrlf=true and overrides the system-wide config.

I suppose that is not exactly like that. Fork doesn't even know about any other git instances in your system and their local configs.

[mjomble]

It seems like on Windows, there is a fourth level of git config that applies across all Git instances:
git-for-windows/git@153328b

%PROGRAMDATA%\Git\config appears in the output for git config --list --show-origin in Fork's command line as well.

Seems like what I previously called system-wide is called Windows-wide in that commit.

To figure out the right names for the rest, I tested with the --global and --system flags and on my computer:

• global = C:\Users\%USERNAME%\.gitconfig in both contexts
• system = %LOCALAPPDATA%\Fork\git\mingw64\etc\gitconfig when running from Fork and C:/Program Files/Git/mingw64/etc/gitconfig when running from regular command line

So my conclusion is that Fork's system level conf overrides the Windows-wide conf.
And the (user-specific) global conf overrides Fork's system level conf.

In any case, I agree that configuring autocrlf on the global level is recommended :)

[alenl]

Chiming in just in case this can help someone in the futute:

As for now open git terminal using the button on the toolbar in Fork and set git config --global core.autocrlf false. It should work.

This didn't work for me. I did that, and then ran git config -l, it was still showing true. What did work was
git config --system core.autocrlf false . Then it worked as intended. (I did that all inside the in-fork terminal as instructed above.)

For the reference, this is for a repo that is inside a WSL sandbox, and is accessed by Fork through a //wsl$/... path.

[joshyeeseequent]

hey @alenl, ive set autocrlf to false in both global git and fork git, however the local changes .sh files still remain. do i need to reclone this repository?

[DanPristupov]

@joshyeeseequent most likely this file is executable (+x) and Windows file system doesn't support the executable flag.

git config --show-origin core.filemode

#645 (comment)

[joshyeeseequent]

@DanPristupov Hey! for some reason git didnt notify me that you replied. Thank you so much! I've done a little bit of poking around with
git config --global core.filemode false
and it seems like my problems are fixed for now! any other repos that arent changed by the global config, i just use the
git config core.filemode false on the repo individually through the fork console. Seems to be good.

Thanks so much for the instant reply! and for reviving a super old thread :)

[marchy]

This unfortunately still seems to be present.

Running on new MacOS machine with new Fork v2.32. Tried setting both global and repo-local configs as per mentioned above but files keep resetting themselves to CRLF

hey @alenl, ive set autocrlf to false in both global git and fork git, however the local changes .sh files still remain. do i need to reclone this repository?

Was there ever an option of sorts incorporated into Fork itself to configure this?

[DanPristupov]

@marchy this is the Windows version issue tracker.

Is it possible that repo was originally cloned on other system (on Windows) and copied to Mac? This way you must reclone it on Mac.

Was there ever an option of sorts incorporated into Fork itself to configure this?

No, you must use command line to configure core.autocrlf