GIT-APPLY(1)

📦
version 2.56.0 · 25 versions
, in arch rolling

💅 NAME 💅 — git-apply(1), Git Manual

okay so this is git-apply from the Git Manual, and its whole thing is literally Apply a patch to files and/or to the index 💖. That's the headline, bestie. No cap.

✨ SYNOPSIS ✨

git apply [--stat] [--numstat] [--summary] [--check]
          [--index | --intent-to-add] [--3way] [--ours | --theirs | --union]
          [--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse]
          [--allow-binary-replacement | --binary] [--reject] [-z]
          [-p<n>] [-C<n>] [--inaccurate-eof] [--recount] [--cached]
          [--ignore-space-change | --ignore-whitespace]
          [--whitespace=(nowarn|warn|fix|error|error-all)]
          [--exclude=<path>] [--include=<path>] [--directory=<root>]
          [--verbose | --quiet] [--unsafe-paths] [--allow-empty] [<patch>...]

🦋 DESCRIPTION 🦋

So, bestie: it reads the supplied diff output — yes, "a patch" — and applies it to files. No cap. When you're running from a subdirectory inside a repository, patched paths outside that directory are ignored. Lowkey important 🫶.

With the --index option, the patch is also applied to the index, and with the --cached option, the patch is only applied to the index. Without these options, the command applies the patch only to files, and it does not require them to be in a Git repository at all. Iconic behavior, honestly ✨.

One big thing: this command applies the patch but does not create a commit 💀. If you want commits from patches generated by git-format-patch(1) and/or received by email, use git-am(1). Periodt. 👑

✨ OPTIONS ✨

  • <patch>... — the actual files you're pulling the patch from, bestie. And yeah, - works too — that reads straight from standard input. slay.
  • --stat — instead of actually applying anything, it just spits out a diffstat for whatever you fed it. cute little summary moment. Turns off "apply".
  • --numstat — basically --stat's more machine-friendly sibling 🫶 — it shows how many lines got added and deleted, in decimal notation, plus the pathname with no abbreviation. For binary files it outputs two - instead of saying 0 0. Turns off "apply".
  • --summary — again, no applying. Instead it gives you a condensed summary of the info it grabbed from the git diff extended headers — creations, renames, mode changes, all that good stuff. Turns off "apply".
  • --check — a vibe check, but for patches 😌. Instead of applying, it checks whether the patch is even applicable to the current working tree and/or the index file, and it detects errors. Turns off "apply".
  • --index — applies the patch to both the index and the working tree (or, if --check is in effect, it just checks it'd land cleanly on both). Heads up though, no cap: --index expects the index entries and the working tree copies for the relevant paths to be identical — contents and metadata like file mode must match. If they don't match it'll throw an error, even if the patch would apply cleanly to the index and working tree separately. rude but fair 💅
  • --cached — applies the patch to just the index, leaving the working tree completely untouched. If --check is in effect, it merely checks it'd apply cleanly to the index entry.
  • -N, --intent-to-add — when you're applying only to the working tree, this marks new files to be added to the index later (peep the --intent-to-add option in git-add(1)). It gets ignored if --index or --cached are used, and it does absolutely nothing outside a Git repository, jsyk. Also note that --index could be implied by other options, like --3way 👀
  • -3, --3way — attempts a 3-way merge when the patch records the identity of the blobs it's supposed to apply to and those blobs are available locally. It may leave the conflict markers in the files in the working tree for you to resolve — yes, you, good luck bestie 😭. This one implies --index unless --cached is used, and it's incompatible with --reject. When you use it with --cached, any conflicts get left at higher stages in the cache.
  • --ours, --theirs, --union — instead of leaving conflicts chilling in the file, it resolves them favouring our side, their side, or both sides of the lines respectively. Requires --3way, so no skipping steps 💅
  • --build-fake-ancestor=<file> — newer git diff output has embedded index info for each blob, which helps identify the original version the patch applies to. Give this flag and, if the original blob versions are available locally, it builds a temporary index containing those blobs 🎀

When it runs into a pure mode change (which has no index information), the info gets read from the current index instead.

  • -R, --reverse — apply the patch in reverse. time travel era ⏪
  • --reject — okay so for atomicity, git apply by default fails the whole patch and doesn't touch the working tree at all when some hunks don't apply. This option changes that: it applies the parts that are applicable and leaves the rejected hunks in corresponding *.rej files. 🫶
  • -z — when --numstat has been given, this stops it from munging pathnames and instead uses a NUL-terminated machine-readable format.

Without this option, pathnames with "unusual" characters get quoted as explained for the config variable core.quotePath (see git-config(1)).

  • -p<n> — removes <n> leading path components (separated by slashes) from traditional diff paths. Like, with -p2, a patch against a/dir/file gets applied directly to file. The default is 1.
  • -C<n> — makes sure at least <n> lines of surrounding context match before and after each change. When fewer lines of surrounding context exist, they all have to match. By default, no context is ever ignored.
  • --unidiff-zero — so by default git apply expects the patch to be a unified diff with at least one line of context, which is a great safety measure 🛡️ — but it totally breaks down when you're applying a diff generated with --unified=0. To bypass those checks, use --unidiff-zero.
Ngl, for the reasons above, using context-free patches is discouraged. it's giving risky behavior 🙈
  • --apply — if you used any of the options marked "Turns off apply" above, git apply just reads and outputs the requested info without actually applying the patch. Drop this flag after those flags and it'll also apply the patch. the comeback arc ✨
  • --no-add — when applying a patch, ignore additions made by the patch. Useful for extracting the common part between two files: run diff on them first, then apply the result with this option — it applies the deletion part but not the addition part. big brain energy 🧠
  • --allow-binary-replacement, --binary — historically we didn't allow binary patch application without explicit user permission, and this flag was how you gave it. Currently we always allow binary patch application, so this is a no-op. it's giving retired icon 👑
  • --exclude=<path-pattern> — don't apply changes to files matching <path-pattern>. Super useful when importing patchsets and you wanna exclude certain files or directories.
  • --include=<path-pattern> — apply changes to files matching <path-pattern>. Also great for importing patchsets when you want to include certain files or directories.

When --exclude and --include patterns are used, they get examined in the order they appear on the command line, and the first match decides whether a patch to each path is used. A patch to a path that matches no include/exclude pattern is used by default if there's no include pattern on the command line — and ignored if there's any include pattern. rules are rules 💅

  • --ignore-space-change, --ignore-whitespace — when applying a patch, ignore changes in whitespace in context lines if necessary. Context lines preserve their whitespace and won't undergo whitespace fixing regardless of the --whitespace value. New lines still get fixed though.
  • --whitespace=<action> — when applying a patch, detects a new or modified line that has whitespace errors 👀. What counts as a whitespace error is controlled by the core.whitespace config. By default, trailing whitespace (including lines that are solely whitespace) and a space character immediately followed by a tab character inside the initial indent of the line are considered whitespace errors.

By default the command outputs warning messages but still applies the patch. When git-apply is used for statistics and not applying a patch, it defaults to nowarn.

You can use different <action> values to control this:

  • nowarn turns off the trailing whitespace warning.
  • warn outputs warnings for a few such errors, but applies the patch as-is (default).
  • fix outputs warnings for a few such errors, and applies the patch after fixing them (strip is a synonym — that's the tool used to consider only trailing whitespace characters as errors, and the fix involved stripping them, but modern Gits do more).
  • error outputs warnings for a few such errors, and refuses to apply the patch.
  • error-all is similar to error but shows all the errors.
  • --inaccurate-eof — under certain circumstances, some versions of diff don't correctly detect a missing new-line at the end of the file 😭. As a result, patches created by those diff programs don't record incomplete lines correctly. This option adds support for applying those patches by working around the bug. we love a workaround 🫶
  • -v, --verbose — reports progress to stderr. By default only a message about the current patch being applied gets printed. This option makes it report additional info. chatty era ✨
  • -q, --quiet — suppresses stderr output. Messages about patch status and progress won't be printed. silence is golden 🤫
  • --recount — don't trust the line counts in the hunk headers, infer them by inspecting the patch instead (like when you edited the patch without adjusting the hunk headers properly 🙈).
  • --directory=<root> — prepends <root> to all filenames. If a -p argument was also passed, it gets applied before prepending the new root.

For example, a patch that talks about updating a/git-gui.sh to b/git-gui.sh can be applied to the file in the working tree modules/git-gui/git-gui.sh by running git apply --directory=modules/git-gui. iconic.

  • --unsafe-paths — by default, a patch that affects stuff outside the working area (either a Git controlled working tree, or the current working directory when git apply is used as a replacement of GNU patch) gets rejected as a mistake (or a mischief 😈).

When git apply is used as a "better GNU patch", you can pass --unsafe-paths to override this safety check. This option has no effect when --index or --cached is in use.

  • --allow-empty — don't return an error for patches containing no diff. That includes empty patches and patches with commit text only. sometimes nothing is something 💜

🎀 CONFIGURATION 🎀

Everything below this line in this section is selectively included from the git-config(1) documentation — the content is exactly the same as what's found there, no cap:

  • apply.ignoreWhitespace — when set to change, tells git apply to ignore changes in whitespace, the same way as the --ignore-space-change option. When set to one of: no, none, never, false, it tells git apply to respect all whitespace differences.
  • apply.whitespace — tells git apply how to handle whitespace, the same way as the --whitespace option.

🦋 SUBMODULES 🦋

If the patch contains any changes to submodules, then git apply treats these changes like so:

  • If --index is specified (explicitly or implicitly), then the submodule commits must match the index exactly for the patch to apply. If any of the submodules are checked-out, those check-outs are completely ignored — like, they're not required to be up to date or clean, and they are not updated. ignored, periodt 💅
  • If --index is not specified, then the submodule commits in the patch are ignored and only the absence or presence of the corresponding subdirectory is checked and (if possible) updated. lowkey minimal effort but valid.

🌈 SEE ALSO 🌈

git-am(1).

👑 GIT 👑

Part of the git(1) suite.

okay that's the whole page bestie, you're officially a git apply expert 🎀✨ this gem is from Git 2.56.0, dated 2026-09-27 — go forth and apply patches responsibly, mwah 💋💖

📦 where this page comes from