Feature: per-repo one-liner to suppress "LF will be replaced by CRLF" advice

[chirag127]

@

Existing issues matching what you're seeing

• I was not able to find an open or closed issue for a dedicated advice knob. The classic thread "warning: LF will be replaced by CRLF in myFile" when using core.autocrlf? #1242 is about the mechanic itself and closed as "working as intended" — not about a suppression switch. No advice.crlfWillReplace (or similarly named) config exists today.

Git for Windows version

git version 2.54.0.windows.1
cpu: x86_64
built from commit: 2b8a3ab140826ac423c2845ef81d4c6ac4f7bf3c
shell-path: D:/git-sdk-64-build-installers/usr/bin/sh
libcurl: 8.19.0
OpenSSL: OpenSSL 3.5.6 7 Apr 2026
zlib: 1.3.2
default-ref-format: files
default-hash: sha1

Windows version

Windows 11

Windows CPU architecture

x86_64 (64-bit)

Additional Windows version information

Microsoft Windows [Version 10.0.26200.8655]

Options set during installation

Editor Option: VisualStudioCode
Default Branch Option: main
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: WinSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Enabled
Enable FSMonitor: Disabled

Other interesting things

Monorepo with 20+ submodules, mixed LF/CRLF content (markdown, JSON, YAML, PowerShell, Bash) shipped on Windows machines and Linux CI.

Terminal/shell

Git Bash (MinTTY) and PowerShell 7

Commands that trigger the issue

# on a freshly cloned repo with default core.autocrlf=true (installer default "CRLFAlways")
$ echo hello > new.txt
$ git add new.txt
warning: in the working copy of 'new.txt', LF will be replaced by CRLF the next time Git touches it

Every git add/git commit on a repo with any LF-only files fires N warnings, one per file. On a batch commit of 40 files that's 40 warning lines drowning the actual output. Real repro from today: adding a normal README.md in a mixed-endings monorepo produces ~30 lines of these before the commit summary appears.

Expected behaviour

I know Git is going to normalise; I chose core.autocrlf=true on purpose; I have a .gitattributes. I want a single documented knob to silence just this advice per repo (or globally) without disabling the normalisation:

git config advice.crlfWillReplace false

…analogous to the existing advice.* family (advice.detachedHead, advice.pushNonFastForward, advice.statusHints, etc). See git-config(1) "advice.*".

Actual behaviour

There is no advice.* knob for this message. Workarounds are all worse than the noise:

1. core.safecrlf=false — silences the warning but also disables the "irreversible normalisation" safety check, which is the wrong trade. Users who want the advice off almost never want that safety off.
2. 2>/dev/null on every git call — buries real errors too.
3. .gitattributes per-file with text / -text — mitigates for listed paths but doesn't globally quiet the advice; still fires for anything not covered.
4. core.autocrlf=input — changes the behaviour, not just the noise. The user wanted true, that's why they picked it in the installer.

Repository

Reproducible on any Windows clone of a Linux-authored repo. Minimal repro:

git init test && cd test
git config core.autocrlf true
git config core.safecrlf true
printf 'line1\nline2\n' > a.txt
git add a.txt   # ← fires the warning

Proposed fix

Add advice.crlfWillReplace (bool, default true) gating the warning: in the working copy of 'X', LF will be replaced by CRLF … message in convert.c (the emitter is around check_safe_crlf / the SAFE_CRLF_WARN code path). This is a ~5-line change, backward-compatible: default true preserves current output; users who set false see the safety check still run but stop being spammed.

Precedent: essentially every other repeated Git advice line got an advice.* toggle by now — this one didn't, and Windows users are the biggest consumers of core.autocrlf=true so we feel it worst.

Happy to attempt a PR against the upstream git/git repo if a maintainer agrees the knob is welcome.
@

[dscho]

Happy to attempt a PR against the upstream git/git repo if a maintainer agrees the knob is welcome.

A patch series for the upstream Git project would be the best course of action (not necessarily a PR, even if you can use GitGitGadget to turn a PR into a patch series).

But before you do that, note that the warning is gated already:

git/convert.c

Lines 217 to 220 in 1242cc4

	else if (conv_flags & CONV_EOL_RNDTRP_WARN)
	warning(_("in the working copy of '%s', LF will be"
	" replaced by CRLF the next time Git touches"
	" it"), path);

The condition is conv_flags & CONV_EOL_RNDTRP_WARN. It is a non-trivial task to follow where conv_flags comes from; Eventually, it comes from here global_conv_flags_eol:

git/object-file.c

Line 38 in 1242cc4

return global_conv_flags_eol | CONV_WRITE_OBJECT;

which in turn is defined via core.safeCRLF:

git/environment.c

Lines 401 to 411 in 1242cc4

	if (!strcmp(var, "core.safecrlf")) {
	int eol_rndtrp_die;
	if (value && !strcasecmp(value, "warn")) {
	global_conv_flags_eol = CONV_EOL_RNDTRP_WARN;
	return 0;
	}
	eol_rndtrp_die = git_config_bool(var, value);
	global_conv_flags_eol = eol_rndtrp_die ?
	CONV_EOL_RNDTRP_DIE : 0;
	return 0;
	}

and its default is warn:

git/environment.c

Line 63 in 1242cc4

int global_conv_flags_eol = CONV_EOL_RNDTRP_WARN;

Therefore, the oneliner you wished for might already exist and be: git config set core.safeCRLF false.

[tboegi]

@chirag127 could you point out the repo which shows this problem ?
The real fix may be to set up the .gitattributes files correctly - and the normalize the repo.
The warnings you describe indicate that there is room for improvements - in the repo.
Or switch them off, as @dscho points out.