Vagrant W/ Windows as Host, Files Don't Run on Vm Due to Crlf

Vagrant w/ windows as host, files don´t run on vm due to crlf

I would no recommend core.autocrlf to be set to anything else than 'false':

git config --global core.autocrlf false

It is a repository-wide setting, which will apply to all files, including binary ones. As I explain in "Trying to commit Git files but getting: fatal: LF would be replaced by CRLF in <some file in repo>", it can corrupt those.

If, for a certain type of files, you need to make sure of the EOL used in them, se a .gitattributes file in which you declare a core.eol directive.

To control what line ending style is used in the working directory, use the eol attribute for a single file and the core.eol configuration variable for all text files.

# Declare files that will always have CRLF line endings on checkout.
*.css text eol=lf
*.html text eol=lf
*.js text eol=lf

(see this codewall example, by Scott Grogan (ninjascribble))

Trying to commit Git files but getting :: fatal: LF would be replaced by CRLF in some file in repo

You might want to set core.safecrlf to "warn", if you want only warning and not a fatal error.

From "git config" mange page:

core.safecrlf

If true, makes git check if converting CRLF is reversible when end-of-line conversion is active. Git will verify if a command modifies a file in the work tree either directly or indirectly.

For example, committing a file followed by checking out the same file should yield the original file in the work tree. If this is not the case for the current setting of core.autocrlf, git will reject the file.

The variable can be set to "warn", in which case git will only warn about an irreversible conversion but continue the operation.

CRLF conversion bears a slight chance of corrupting data.

When it is enabled, git will convert CRLF to LF during commit and LF to CRLF during checkout.

A file that contains a mixture of LF and CRLF before the commit cannot be recreated by git.

For text files this is the right thing to do: it corrects line endings such that we have only LF line endings in the repository.

But for binary files that are accidentally classified as text the conversion can corrupt data.

If you recognize such corruption early you can easily fix it by setting the conversion type explicitly in .gitattributes.

Right after committing you still have the original file in your work tree and this file is not yet corrupted. You can explicitly tell git that this file is binary and git will handle the file appropriately.

Unfortunately, the desired effect of cleaning up text files with mixed line endings and the undesired effect of corrupting binary files cannot be distinguished.

In both cases CRLFs are removed in an irreversible way. For text files this is the right thing to do because CRLFs are line endings, while for binary files converting CRLFs corrupts data.

I prefer identifying the exact files or types of file I want to force the eol with .gitattributes files only (with core.eol settings, which you have), and leave autocrlf to false.

In case of text fiels with mixed eol, this blog post suggests, for instance, to:

If you have Notepad++ installed in your computer, simply follow these steps.

1. Open the file that is having the Fatal issue.
2. Click Edit -> EOL Conversion then select Windows Format or to any that you’re having an issue committing.

---

Warning, if you have Git 2.17 or 2.18: a regression introduced in 8462ff4 ("convert_to_git(): safe_crlf/checksafe becomes int conv_flags", 2018-01-13, Git 2.17.0) back in Git 2.17 cycle caused autocrlf rewrites to produce a warning message despite setting safecrlf=false.

See commit 6cb0912 (04 Jun 2018) by Anthony Sottile (asottile).

^{(Merged by Junio C Hamano -- gitster -- in commit 8063ff9, 28 Jun 2018)}

Dev provisioning with Vagrant + Ansible not working

Miraculously, things just started working as I updated my Vagrant and my Ansible versions. I really don't know what happened. Now I am running on Vagrant 1.3.5 and Ansible 1.4 (devel 6008ea40ee).

Thanks everyone for the answers.

Error 'unexpected end of file /vagrant/provision/prep_server.sh' by vagrant up command

Your file has carriage return encoded by windows which is different in linux world.

Your solutions:

1. run your file through dos2unix script (http://dos2unix.sourceforge.net)

2. most advanced editors on windows (UltraEdit, Notepad++) allows you to save the format of the file specifically for linux (for example UltraEdit has File/convert with option to convert for linux)

Working on Windows, but getting LF will be replaced by CRLF when committing in Git

Git has two places that line feeds can be controlled:

• In the global config settings on your system
• In the .gitattributes file that applies per repo/project. These settings will override the user's configuration settings.

In your Git settings your have core.autocrlf=true. Meaning you are telling Git to change the line ending to CRLF. You can change this to see if Git stops trying to change the line endings.

git config --global core.autocrlf input

A better approach may be to set the proper line endings in the .gitattributes file. This is committed to the repository in the root and it will overrides user's individual settings. This ensures that all users committing to the repo will have the proper line endings. Because it sounds like you are working on *nix based project it would probably be prudent to set the line endings to line feed. In the .gitattribute files you could have something like this.

# Set all files to have LF line endings
* text eol=lf

This link has a more detailed explanation of the options you can set in the file: https://help.github.com/articles/dealing-with-line-endings/

EDIT 1: Thought I add this from the actual Git documentation: https://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration

core.autocrlf

If you’re programming on Windows and working with people
who are not (or vice-versa), you’ll probably run into line-ending
issues at some point. This is because Windows uses both a
carriage-return character and a linefeed character for newlines in its
files, whereas Mac and Linux systems use only the linefeed character.
This is a subtle but incredibly annoying fact of cross-platform work;
many editors on Windows silently replace existing LF-style line
endings with CRLF, or insert both line-ending characters when the user
hits the enter key.

Git can handle this by auto-converting CRLF line endings into LF when
you add a file to the index, and vice versa when it checks out code
onto your filesystem. You can turn on this functionality with the
core.autocrlf setting. If you’re on a Windows machine, set it to true
– this converts LF endings into CRLF when you check out code:

$ git config --global core.autocrlf true

If you’re on a Linux or Mac
system that uses LF line endings, then you don’t want Git to
automatically convert them when you check out files; however, if a
file with CRLF endings accidentally gets introduced, then you may want
Git to fix it. You can tell Git to convert CRLF to LF on commit but
not the other way around by setting core.autocrlf to input:

$ git config --global core.autocrlf input

This setup should leave you
with CRLF endings in Windows checkouts, but LF endings on Mac and
Linux systems and in the repository.

If you’re a Windows programmer doing a Windows-only project, then you
can turn off this functionality, recording the carriage returns in the
repository by setting the config value to false:

$ git config --global core.autocrlf false

---

Related Topics