Converting a Git repo from tabs to spaces (2016)

Original Article ↗ Hacker News Discussion ↗

Tabs vs. spaces: consistency vs. flexibility

  • Several comments argue that consistency within a codebase matters more than which style you choose; others say the article convinced them that tabs’ variable rendering across tools (IDE vs. GitHub, etc.) is a real problem and pushes them toward spaces.
  • Pro‑tab participants emphasize the semantic meaning of “one tab = one indent level” and the ability for each developer to choose their own visual width. They see this as separation of storage vs. view.
  • Pro‑space participants emphasize predictable alignment, enforcement of column limits, and avoiding issues when different tools or developers choose different tab widths.
  • Some suggest hybrid rules: tabs only for leading indentation, spaces for alignment after that; others criticize this as fragile with auto-formatters.

Accessibility, aesthetics, and editor behavior

  • Tabs are defended as an accessibility feature: different users (e.g., with visual or cognitive needs) can pick small or large indentation widths without affecting others.
  • Opponents counter that fixed-width spaces correlate in practice with cleaner, more readable code, and that tabs’ variable width complicates column-limit policies and visual layout.
  • There’s meta‑discussion that editors could abstract this away at the syntax-tree level so everyone sees their preferred formatting, but tooling for this is rare.

Whitespace, control characters, and history

  • One view: tabs are control characters that “don’t belong” in text files; others call this absurd and note that other control characters (line feeds) are ubiquitous.
  • Historical use of tabs for table alignment (typewriters, word processors) is noted, contrasted with modern use for indentation.

Git blame and mass reformatting

  • Many focus on the impact of a tabs→spaces conversion on git blame.
  • Solutions cited:
    • .git-blame-ignore-revs / --ignore-revs-file, now also supported by GitHub.
    • git blame -w to ignore whitespace-only changes.
    • Some wish ignore metadata were stored in commits; others raise security/abuse concerns and prefer viewer-side configuration.

Tooling and workflows

  • EditorConfig and language-specific formatters (e.g., dotnet format, clang-format, gofmt) are mentioned as ways to standardize indentation and run either via CI or git hooks.
  • Some criticize the article’s approach as overcomplicated, preferring simple one-time conversions (e.g., expand or sed) plus a single “mechanical change” commit, while noting exceptions like Makefiles that must keep tabs.