Useful Config Settings: autocrlf, safecrlf, push.default, pull.rebase, rerere
With all four configuration levels now understood, this lesson covers a curated, genuinely practical set of specific settings worth knowing well — solving real, common problems around cross-platform line endings, pushing behavior, and pull/rebase defaults, several of which directly extend concepts from earlier modules.
Learning Objectives
- Configure autocrlf and safecrlf to handle cross-platform line ending differences correctly.
- Understand push.default and choose the appropriate value for typical workflows.
- Set pull.rebase globally to make Module 4's pull --rebase the default behavior.
- Recognize rerere as a setting worth knowing exists, with full coverage in the next lesson.
Key Terms to Know Before Configuring These Git Settings
- core.autocrlf: A setting controlling automatic conversion between Windows-style (CRLF) and Unix-style (LF) line endings when files are checked out and committed.
- core.safecrlf: A setting that warns or blocks a commit if a line-ending conversion would be irreversible, catching potential autocrlf misconfigurations.
- push.default: A setting controlling which branch(es) a plain git push actually pushes to, when no explicit remote/branch is specified.
- pull.rebase: A setting that, when enabled, makes a plain git pull behave like git pull --rebase (Module 4) by default.
How These Useful Git Config Settings Actually Work
**`core.autocrlf`** addresses a genuinely common cross-platform headache: Windows traditionally uses CRLF (carriage return + line feed) line endings, while macOS and Linux use just LF (line feed). Without any handling, a file edited on Windows and one edited on macOS can show every single line as 'changed' in a diff, purely due to this invisible line-ending difference, even when the actual text content is identical — extremely confusing and disruptive to collaboration across platforms. `autocrlf` solves this by automatically converting line endings during checkout and commit:
```
# On Windows: convert LF to CRLF on checkout, convert back to LF on commit
git config --global core.autocrlf true
# On macOS/Linux: don't convert on checkout, but ensure LF on commit (recommended)
git config --global core.autocrlf input
```
The distinction matters: Windows developers typically want `true` (files use CRLF locally, matching Windows-native tooling expectations, but are normalized to LF when actually stored in the repository), while macOS/Linux developers typically want `input` (never convert on checkout, but ensure anything committed uses LF, guarding specifically against an accidental CRLF file being introduced by, say, a Windows collaborator or a misconfigured tool).
**`core.safecrlf`**, often paired with `autocrlf`, adds a safety check: if a line-ending conversion during commit would be irreversible (converting back and forth wouldn't restore the exact original bytes, which can happen with certain binary-like content misidentified as text), this setting can warn or outright refuse the commit, catching a whole class of subtle, hard-to-diagnose autocrlf misconfiguration issues before they corrupt a file's content in history.
**`push.default`** controls what a plain `git push` (Module 4), with no explicit remote or branch specified, actually does. The modern, generally recommended value is `simple` (and has in fact been Git's own default for some years now): it pushes only the current branch, and only to its configured upstream (tracking) branch of the *same name* — a safe, predictable, unsurprising behavior. Older or alternative values like `matching` (pushes every local branch that has a same-named remote counterpart) can produce surprising, unintended pushes of multiple branches at once, which is exactly why `simple` became the safer modern default:
```
git config --global push.default simple
```
**`pull.rebase`**, already introduced conceptually in Module 4's `git pull --rebase` lesson, is the config setting that makes that rebase-based pull behavior the **default** for every plain `git pull`, without needing to remember the `--rebase` flag each time:
```
git config --global pull.rebase true
```
Finally, **`rerere`** (`rerere.enabled`) is worth knowing exists here, with its full, dedicated explanation reserved for the very next lesson, since it deserves deeper treatment than a brief mention — it's a genuinely powerful setting for anyone dealing with repeated, similar merge conflicts.
autocrlf Line Ending Handling: Visual Walkthrough
Draw a side-by-side comparison of autocrlf=true (Windows) vs autocrlf=input (macOS/Linux). LEFT 'autocrlf=true': 'Repository (LF)' ↔ (bidirectional conversion arrows) ↔ 'Working directory (CRLF)' captioned 'Converts BOTH ways — checkout gets CRLF, commit converts back to LF.' RIGHT 'autocrlf=input': 'Repository (LF)' → (one-way arrow only) → 'Working directory (unchanged, whatever it already is)' captioned 'Only ensures LF on COMMIT — never converts on checkout.' Beneath both, add a small push.default comparison: 'push.default=simple: plain git push only pushes current branch to its SAME-NAME upstream — safe, predictable.'
Useful Git Config Settings: Quick Reference Table
| Setting | Recommended Value | Solves |
|---|---|---|
| core.autocrlf | true (Windows) / input (macOS/Linux) | Cross-platform line ending inconsistency causing false diffs |
| core.safecrlf | warn or true | Catches irreversible/unsafe line ending conversions before they corrupt content |
| push.default | simple (modern Git default) | Prevents surprising, unintended pushes of unrelated branches |
| pull.rebase | true | Makes plain git pull behave like pull --rebase (Module 4) by default |
Setting Useful Config Values: Command Syntax and Examples
# On Windows: convert CRLF/LF appropriately on checkout and commit
git config --global core.autocrlf true
# On macOS/Linux: only normalize to LF on commit, don't convert on checkout
git config --global core.autocrlf input
# Warn about (or block) unsafe, irreversible line-ending conversions
git config --global core.safecrlf warn
# Ensure plain 'git push' only pushes the current branch to its matching upstream
git config --global push.default simple
# Make plain 'git pull' behave like 'git pull --rebase' by default (Module 4)
git config --global pull.rebase true
# Confirm all currently active settings
git config --list | grep -E 'autocrlf|safecrlf|push.default|pull.rebase'Breaking Down the Config Settings Example
Each command sets one specific, practically valuable configuration globally, applying across all of the user's repositories (Module 1's global level, revisited in the previous lesson). The `autocrlf` examples show the platform-appropriate value for Windows versus macOS/Linux, directly addressing the cross-platform line-ending problem. `safecrlf` is set to `warn`, a moderate choice that alerts to a potential problem without outright blocking every commit. `push.default simple` and `pull.rebase true` configure two of the most commonly recommended defaults for predictable, low-surprise push and pull behavior, directly connecting back to Module 4's original coverage of both commands.
How These Settings Solve Real Problems on Engineering Teams
- Cross-platform teams (with a mix of Windows, macOS, and Linux developers) almost universally need to address autocrlf configuration explicitly, since the default, unconfigured behavior frequently causes confusing, noise-filled diffs purely from line-ending differences.
- push.default simple has been Git's own actual default since version 2.0, specifically because the older matching behavior caused enough real, disruptive incidents of developers accidentally pushing unrelated branches together.
- Many teams' onboarding documentation includes a recommended .gitconfig snippet or setup script covering exactly these settings (autocrlf, push.default, pull.rebase), ensuring consistent behavior across every new team member's machine from day one.
- A .gitattributes file (a related, repository-level mechanism not covered in depth here) is sometimes used alongside or instead of personal autocrlf settings, to enforce consistent line-ending handling for a project regardless of any individual developer's local configuration.
Useful Config Settings Interview Questions and Answers
Q1. What problem does core.autocrlf solve, and what values would you recommend for Windows versus macOS/Linux developers?
It addresses the cross-platform line-ending mismatch between Windows (CRLF) and Unix-based systems (LF), which can otherwise cause every line of a file to appear changed in a diff purely due to line-ending differences. Windows developers typically want autocrlf=true (converting both ways), while macOS/Linux developers typically want autocrlf=input (only normalizing to LF on commit, without converting on checkout).
Q2. What does push.default=simple do, and why is it preferred over older alternatives like matching?
It makes a plain git push only push the current branch, and only to its configured upstream branch of the same name. This is safer and more predictable than the older matching behavior, which pushed every local branch with a same-named remote counterpart, potentially causing surprising, unintended pushes of multiple branches at once.
Q3. How does the pull.rebase config setting relate to Module 4's git pull --rebase?
Setting pull.rebase to true makes that same rebase-based pull behavior — replaying local commits on top of fetched changes instead of merging — the default for every plain git pull, without needing to remember to add the --rebase flag manually each time.
Useful Config Settings Quiz: Test Your Understanding
1. What problem does core.autocrlf solve?
- Merge conflicts between branches
- Cross-platform line-ending inconsistency between Windows (CRLF) and Unix-based systems (LF)
- Slow clone performance
- Incorrect commit messages
Answer: B. Cross-platform line-ending inconsistency between Windows (CRLF) and Unix-based systems (LF)
Explanation: autocrlf manages automatic conversion between CRLF and LF line endings during checkout and commit, preventing false, line-ending-only diffs across different operating systems.
2. What does push.default=simple ensure a plain git push does?
- Pushes every local branch at once
- Pushes only the current branch, to its configured upstream branch of the same name
- Force-pushes regardless of conflicts
- Prevents pushing entirely without an explicit branch name
Answer: B. Pushes only the current branch, to its configured upstream branch of the same name
Explanation: The simple value, Git's modern default, provides safe, predictable push behavior, avoiding the surprise of unintentionally pushing multiple unrelated branches at once.
3. What does setting pull.rebase to true accomplish?
- Disables pulling entirely
- Makes plain git pull behave like git pull --rebase by default
- Automatically resolves all merge conflicts
- Prevents any commits from being pulled
Answer: B. Makes plain git pull behave like git pull --rebase by default
Explanation: This setting makes the rebase-based integration behavior from Module 4's git pull --rebase the automatic default for every plain git pull, without needing the flag typed manually each time.
Common Mistakes With These Config Settings
- Using the wrong autocrlf value for a given platform (e.g., true on macOS/Linux instead of input), causing unwanted, unnecessary line-ending conversions on checkout.
- Not configuring autocrlf at all on a cross-platform team, leading to confusing, noise-filled diffs purely from line-ending mismatches between collaborators' operating systems.
- Sticking with the older push.default=matching behavior (if inherited from an old configuration) without realizing simple is the safer, modern recommended default.
- Forgetting that pull.rebase=true is a personal/global convenience setting, not something that changes what a plain git pull does for teammates who haven't set it themselves.
Useful Config Settings: Exam-Ready Quick Notes
- core.autocrlf: true (Windows, converts both ways) or input (macOS/Linux, only normalizes to LF on commit).
- core.safecrlf: warns/blocks on irreversible line-ending conversions, catching autocrlf misconfigurations.
- push.default=simple: plain git push only pushes current branch to its same-name upstream (modern Git default).
- pull.rebase=true: makes plain git pull behave like pull --rebase (Module 4) by default.
Useful Config Settings: Key Takeaways
- autocrlf and safecrlf together solve a genuinely common, disruptive cross-platform line-ending problem for teams mixing Windows and Unix-based developers.
- push.default=simple provides safe, predictable push behavior, avoiding the surprises of older alternative values.
- pull.rebase=true turns Module 4's manually-flagged pull --rebase into a personal, global default, removing the need to remember the flag.
Frequently Asked Questions About These Config Settings
Q1. What does core.autocrlf do, and what value should I use?
It manages automatic conversion between Windows-style (CRLF) and Unix-style (LF) line endings, preventing confusing, line-ending-only differences from appearing in diffs. Windows developers typically want it set to true; macOS and Linux developers typically want it set to input.
Q2. What is core.safecrlf for?
It's a safety check that warns or blocks a commit if a line-ending conversion during that commit would be irreversible, catching potential autocrlf misconfiguration issues before they can corrupt a file's content in the repository's history.
Q3. What does push.default=simple do?
It ensures a plain git push (with no explicit remote or branch specified) only pushes your current branch to its configured upstream branch of the same name, avoiding the risk of accidentally pushing multiple unrelated branches at once.
Q4. How do I make git pull always behave like git pull --rebase without typing the flag?
Set pull.rebase to true globally: git config --global pull.rebase true. This makes every future plain git pull use the rebase-based integration behavior by default, exactly as covered in Module 4.
Q5. What is rerere, and where can I learn more about it?
It's a Git feature for automatically reusing recorded conflict resolutions when the same conflict recurs. It's introduced here briefly, but covered in full, dedicated depth in the very next lesson of this module.
Summary
A curated set of Git configuration settings solves genuinely common, practical problems. `core.autocrlf` (set to `true` on Windows, `input` on macOS/Linux) manages automatic conversion between CRLF and LF line endings, preventing confusing, line-ending-only diffs between developers on different operating systems, while `core.safecrlf` adds a safety check, warning or blocking commits where such a conversion would be irreversible. `push.default=simple`, Git's own modern default, ensures a plain `git push` only pushes the current branch to its matching-named upstream, avoiding the surprising, unintended multi-branch pushes that older alternative values could cause. `pull.rebase=true` makes Module 4's `git pull --rebase` behavior the automatic default for every plain `git pull`, without needing the flag remembered each time. `rerere` is mentioned here as a setting worth knowing about, with its full, dedicated explanation covered in the very next lesson.