How to Copy Git Commit Messages Without Wrap Damage

A git commit message has a convention: the subject line is 50 characters or fewer, the body wraps at 72 characters, and a blank line separates subject from body. The convention is older than GitHub and is documented in the git source itself. When a developer copies a commit message from a browser, an IDE, or a chat tool, the wrapping often breaks. The subject and body merge into a single paragraph, or the body's hard wraps are stripped and replaced with soft wrapping that depends on the destination. The commit that lands in git history is then either malformed or unreadable in git log. This guide covers the convention, what breaks it, and how to paste a clean commit message.

For neighbouring topics, see remote SSH in VS Code and the local clipboard, gists vs clipboard for sharing throwaway code, and best clipboard habits for developers in 2026. For path-related git topics, see git paths, SHAs, and PR URLs: a pin set.

The 50/72 rule

The 50/72 rule is a writing convention for git commit messages, not a git-enforced limit. Git itself accepts any line length. The convention comes from the Linux kernel mailing list and was popularised by Tim Pope's "A Note About Git Commit Messages" in 2008. The rule:

• Subject line: 50 characters or fewer. Imperative mood ("Add feature", not "Added feature" or "Adds feature"). No trailing period.
• Blank line between subject and body. Git uses this to distinguish subject from body in git log --oneline and in email-based workflows.
• Body: wrapped at 72 characters. Hard wraps, not soft wraps — the body lines should each end with a newline, not rely on the viewer to wrap.
• Body content: explain what and why, not how. The diff already shows how.

A conformant commit message:

Add retry logic to payment client

The payment client previously failed silently when the upstream
returned a 503. This commit adds a retry with exponential backoff
(up to three attempts) and logs each retry at warn level. The
change is gated behind a feature flag, `payment_retry_v2`, which
defaults to off.

Refs: PROJ-1234

The subject is 36 characters. The body lines are all under 72 characters. The blank line separates subject and body. The Refs: footer is on its own line.

Why hard wraps matter

Git stores the commit message as-is. If the body is a single long line, git log displays it as a single long line, which is unreadable in a terminal. If the body is hard-wrapped at 72, git log displays it as the author intended, regardless of the terminal width.

The hard wrap also matters for git format-patch and git send-email, which convert commits to email messages. Email has a 78-character line limit by convention (RFC 2822 recommends 78, with a hard limit of 998). A commit message with lines over 78 characters can break in email-based workflows, though this is rare outside the kernel and a few other projects.

The 72-character wrap is a compromise: it leaves room for quoting in email replies (each quote level adds a > and a space) and for git's own indentation in git log output.

What breaks the wrap when copying

The Windows clipboard carries text as a sequence of characters, including newlines. When a developer copies a commit message, the newlines in the source are preserved on the clipboard. The problem is that the source's newlines may not be the right newlines.

GitHub's commit view

GitHub's commit page (github.com/user/repo/commit/SHA) renders the commit message as HTML. The subject is in a heading; the body is in a paragraph with white-space: pre-wrap. When the developer selects the text and copies, the browser places the text on the clipboard with the newlines preserved in most cases, but the pre-wrap rendering can introduce soft wraps that look like hard wraps.

The fix: copy from the raw commit view. Append .patch to the commit URL (github.com/user/repo/commit/SHA.patch) to get the raw git format-patch output, which has the correct hard wraps. Copy from there.

IDE commit dialogs

VS Code's source control panel has a commit message box. The box does not enforce a 50/72 wrap; it accepts any text. A developer who types a long subject and a body without hard wraps produces a commit message that violates the convention.

JetBrains IDEs (IntelliJ, PyCharm, WebStorm) have a commit message editor with an optional 50/72 guideline. The guideline is a visual ruler, not a hard wrap; the developer still has to insert the newlines themselves.

The fix: configure the IDE's commit editor to wrap at 72. VS Code does not have a built-in setting for this, but the git-commit-message-editor extension does. JetBrains IDEs have the setting under Settings → Version Control → Commit → Commit message.

Chat tools and email

A commit message drafted in a Slack DM or an email and then copied into a git commit often arrives with the chat tool's soft wraps converted to hard wraps at the wrong width. Slack wraps at roughly 70-80 characters depending on the window width; the wrap is visual, not in the underlying text, but when copied, Slack inserts newlines at the visual wrap points. The result is a commit body with newlines at varying widths, none of which match the 72-character convention.

The fix: draft commit messages in a plain text editor, not in a chat tool. If a draft must be shared in chat, share it as a file attachment or a code block, not as a paragraph.

Pasting a commit message

When the commit message is on the clipboard, the way it is pasted matters:

• git commit without -m: opens the configured editor (core.editor). The clipboard is pasted into the editor, which preserves the newlines. This is the safest paste path.
• git commit -m "subject" -m "body": each -m becomes a paragraph. The body is a single string; newlines within it are preserved if the shell quotes them correctly. This works for short bodies but is error-prone for longer ones.
• git commit -F -: reads the commit message from stdin. Pipe the clipboard contents: powershell.exe Get-Clipboard | git commit -F -. This is the most reliable paste path on Windows, because it bypasses the shell's quoting entirely.

The -F - approach is the recommended pattern when the commit message is already on the clipboard. It reads the message verbatim, preserving all newlines, and does not require opening an editor.

Fixing a broken wrap after commit

If a commit message was committed with the wrong wrap, it can be amended if it is the most recent commit:

git commit --amend

This opens the editor with the existing message. Fix the wrap, save, and the commit is updated. The commit's SHA changes, so this is safe only for commits that have not been pushed.

For an older commit in a branch that has not been pushed, git rebase -i with reword opens the editor for each commit being reworded. For commits that have been pushed, rewriting history requires a force-push and coordination with anyone who has pulled the branch.

The cleaner approach is to get the wrap right before committing. The 50/72 convention is not enforced by git, but it is enforced by review: a maintainer who sees a commit message with the wrong wrap will request a reword.

Subject-only commits

For trivial commits, a subject-only message is acceptable. The convention:

Fix typo in README

No body, no blank line. Git accepts this. The 50-character subject limit still applies.

The temptation to add an empty body ("Fix typo in README\n\n\n") should be resisted. The blank line is meaningful: it tells git that what follows is the body. An empty body is not the same as no body.

Multi-paragraph bodies

For commits with multiple paragraphs in the body, each paragraph is separated by a blank line. Within a paragraph, lines are hard-wrapped at 72:

Add retry logic to payment client

The payment client previously failed silently when the upstream
returned a 503. This commit adds a retry with exponential
backoff (up to three attempts) and logs each retry at warn
level.

The change is gated behind a feature flag, `payment_retry_v2`,
which defaults to off. The flag can be removed in a follow-up
once the retry logic has been validated in production.

Refs: PROJ-1234

The blank line between paragraphs is part of the convention. Without it, the paragraphs merge in git log.

Footers

Commit message footers (Refs:, Signed-off-by:, Co-authored-by:, Fixes:) go after the body, separated by a blank line. Each footer is on its own line. Git parses these footers for various purposes: Fixes: closes issues, Signed-off-by: is used by some projects for certification, Co-authored-by: is rendered by GitHub as a co-author attribution.

A footer is a single line; it is not wrapped at 72. The convention is to keep footers short enough to fit on one line.

A short checklist

• Subject: 50 characters or fewer, imperative mood, no trailing period.
• Body: hard-wrapped at 72 characters, blank line between subject and body.
• Multi-paragraph body: blank line between paragraphs.
• Footers: on their own lines, after a blank line.
• Draft in a plain text editor, not in a chat tool.
• Paste with git commit -F - for the most reliable newline preservation.
• Amend before pushing if the wrap is wrong.

Background for this constraint is Monorepo Paths Are Long: Pin the Ones You Use.

Related reading

• Gists vs Clipboard for Sharing Throwaway Code
• Monorepo Paths Are Long: Pin the Ones You Use
• Best Clipboard Habits for Developers in 2026
• Clipboard Tools on Multi-Monitor Windows Setups

Sources

• Git — Contributing to a project (commit guidelines) — official Git Book chapter documenting the commit message convention, including the 50/72 rule
• Tim Pope — A Note About Git Commit Messages — the original 2008 post that popularised the 50/72 rule, referenced by most subsequent documentation
• Git — git-commit man page — official git-commit documentation, including the -F flag for reading the commit message from a file or stdin
• GitHub Docs — Commit message guidelines — GitHub's guidance for editing commit messages, including the convention for subject and body
• IETF — RFC 2822: Internet Message Format — the email format standard that imposes the 78-character line convention, which is the historical reason for the 72-character git body wrap

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support