How Core Git Developers Configure Git

Original Article ↗ Hacker News Discussion ↗

Global ignores and editor/IDE files

  • Several people like a global ignore file ($XDG_CONFIG_HOME/git/ignore), e.g. for .DS_Store or personal .envrc, so they don’t pollute project .gitignores.
  • Others warn that hiding files only locally can surprise collaborators, since those files aren’t ignored in the repo.
  • Strong disagreement over committing editor/IDE directories like .vscode:
    • Pro: shared debug/launch/tasks settings benefit all VS Code users; VS Code config is hierarchical and composable.
    • Con: repo clutter, tool-specific noise, and lack of similar treatment for other IDEs; prefer .editorconfig or global config.

Local-only ignores

  • .git/info/exclude is highlighted as a useful per-repo ignore that doesn’t touch tracked files or shared .gitignore.
  • Some just put such patterns in their global ignore and force-add when needed.

Diffs, conflict styles, and tooling

  • Many readers immediately adopted diff-related settings: diff.algorithm=histogram, diff.colorMoved, merge.conflictStyle=zdiff3, whitespace highlighting, etc.
  • Strong praise for three-way conflict styles (diff3/zdiff3) as making some conflicts solvable or at least mechanically resolvable.
  • Third-party tools get lots of love: difftastic, delta, diff-so-fancy, bat as pager, kdiff3, etc.
  • A few reverted from delta back to plain diffs because pretty output complicates copying patches or small terminals, though piping/redirecting is noted as a workaround.

CLI vs GUI

  • Some mostly use VS Code’s Git UI and find it covers 99.9% of needs; graphical diffs and merge UIs are praised.
  • Others argue you should gradually learn the CLI because GUIs hide model details and fall short for complex history surgery and debugging.

Branch naming: master vs main

  • Sarcastic and serious complaints about the main change: breaks aliases and scripts that assumed master, adds noise in logs/CI, and is viewed by some as unnecessary “word policing.”
  • Specific technical pain around mirrors and symbolic HEAD refs when upstreams rename/delete default branches.
  • Counterpoints: Git only changed defaults for new repos; any repo has always been free to use other names; robust tooling shouldn’t hardcode master. Some simply prefer “main” as shorter/nicer.

Config philosophy, safety, and defaults

  • Many share custom configs and aliases (lg fancy logs, out for unpushed commits, “quick push” functions).
  • Divided views on “clearly better” options:
    • fetch.prune / pruning: fans want remotes to mirror reality; critics fear losing recoverable data and insist deletions stay manual.
    • push.autoSetupRemote: some like auto-publishing branches; others insist this should remain explicit.
  • Wishes for versioned “modern defaults” profiles instead of touching long-stable defaults.
  • Safety suggestions include always using --force-with-lease (often via alias) and enabling commit/tag signing with SSH-based GPG.

Git’s evolution

  • One commenter assumes Git is unchanged in 15 years; replies point out that many highlighted configs are fairly recent quality-of-life features, and that deeper changes like a new hash algorithm are in progress.