Update Git on Mac: Apple's 2.50.1 Missed 29 of 30 Checks

The git that comes with a Mac is 2.50.1. On this Mac mini, running macOS 26.4.1 with Command Line Tools 26.5, /usr/bin/git --version prints git version 2.50.1 (Apple Git-155). Upstream tagged 2.50.1 on June 16, 2025. Since then it has shipped six feature releases, 2.51 through 2.56, and git-scm.com's macOS page lists 2.56.0 as current. Like Python, /usr/bin/git is a 118,928-byte stub that hands off to the 7.6 MB binary inside /Library/Developer/CommandLineTools.

This is the sixth bundled tool I've measured today, after GNU make on Mac, awk on Mac, update Bash on Mac, update Ruby on Mac and update Python on Mac. I expected git to be the exception. Apple has updated it within the last year and a half, and a 16-month-old git sounds fine. Mostly it was: none of the new features I tried did anything harmful. But 29 of the 30 didn't work, 5 of those failed without an error, and the one change that matters most for safety isn't in Apple's build.

Six releases, 157 user-facing changes

Every git release note has a "UI, Workflows & Features" section. Counting its bullet points from 2.51.0 to 2.56.0 gives 21, 24, 14, 40, 22 and 36, which is 157 changes Apple's build doesn't have. The fix sections add another 301 bullets. Some of the 157 are new commands people now see in blog posts and answers: git history (2.54, experimental), git last-modified and git repo (2.52), git url-parse and git format-rev (2.55), and git add --resolved and git branch --delete-merged (2.56).

Scott Chacon ran into this on Hacker News in August. He wanted git history and wrote: "I'm on `2.50.1 (Apple Git-155)`. It turns out I don't actually know how to update that. `brew install git` does not overwrite the system binary." A year before that, another commenter found 2.39.5 (Apple Git-154) on their Mac. The 2.39 line started in December 2022. So the 2.50.1 build was a big jump, and it has been holding still since.

30 probes against three gits

I picked 30 changes from those six release notes that a script or a person could actually depend on. I ran each one on Apple's 2.50.1, on Homebrew's 2.54.0 (what my scheduled jobs use), and on 2.56.0, which I built from the kernel.org tarball. Each git got a fresh repository with a bare remote, a feature branch and a merge, and global and system config were switched off. 25 of the probes are commands or options, where the exit code tells you what happened. The other 5 are config keys or behaviors, where I checked whether the thing actually happened.

On Apple's git, 24 probes failed with an error. Most of the errors are clear enough: git: 'history' is not a git command, error: unknown option `compact-summary', error: unknown subcommand: `exists'. A few are less helpful. git rev-list --maximal-only and --max-count-oldest print the whole rev-list usage text with exit code 129, and git diff-tree --max-depth does the same. In none of those cases does the message mention the git version.

One error is worse than the others. Since 2.52, a path-valued config can start with :(optional), so a team can set blame.ignoreRevsFile=:(optional).git-blame-ignore-revs and not break blame in repos that don't have the file. Apple's git treats the prefix as part of the filename:

$ git -c 'blame.ignoreRevsFile=:(optional).git-blame-ignore-revs' blame a.txt
fatal: could not open object name list: :(optional).git-blame-ignore-revs
$ echo $?
128

So one shared config line that works on 2.52 and later will break git blame for everyone on the stock Mac git.

The 5 that failed without a word

Old git ignores config keys it doesn't recognize, and in these cases that means it skips the work and still exits 0:

Probe	Added	Apple 2.50.1	2.56.0
hook.lint.command + hook.lint.event=pre-commit	2.54	commit exits 0, hook never runs	hook runs
stash.index=true, then stash pop	2.52	exits 0, staged change comes back unstaged	comes back staged
[includeIf "worktree:<path>"]	2.56	included file never read, user.name empty	included
git config list --type=bool	2.54	exits 0, prints t.flag=yes	prints t.flag=true
Sideband control characters from a remote hook	2.55	4 of 4 escape sequences reach the terminal	2 color codes pass, 2 masked as ^[

The config-based hooks are the one I'd worry about. If a team moves its pre-commit checks into a shared config file, a Mac user on the stock git commits with no checks and no warning. Homebrew's 2.54.0 ran the hook.

The includeIf "worktree:" probe also caught me out on 2.56. My first version used a path with a trailing slash, and that matched nothing, because a trailing slash means "worktrees inside this directory," not the directory itself. A /tmp/... path also matched nothing, since git compares against the resolved /private/tmp/.... Neither mistake produced an error.

The change that matters is in 2.55

In January 2025 the git project published CVE-2024-52005, rated high: messages a remote sends over the "sideband" (the remote: lines during clone, fetch and push) reach your terminal unfiltered, so a hostile server can use escape sequences to hide or fake output. The advisory gave no patched upstream version and said the fix was still being discussed on the mailing list. Git 2.55's release notes say sideband control sequences are now "mostly disabled by default, except for ANSI color escape sequences," and a new sideband.allowControlCharacters setting controls it.

I tested it with a pre-receive hook that prints a color code, a reset, a window-title change and a clear-screen. Then I pushed to it from each git and counted raw ESC bytes in stderr. Apple's 2.50.1 passed all 4. Homebrew's 2.54.0 also passed all 4. 2.56.0 passed the 2 color codes and printed the other 2 as a literal ^[. If you clone from hosts you don't control, this is the strongest reason to update. The security advisories list does have one piece of good news. It shows nothing published after July 2025, and Apple's 2.50.1 already includes the July 2025 fixes (CVE-2025-48384 and six others, per the 2.50.1 notes).

How to update git on a Mac

You can't replace /usr/bin/git, and you shouldn't try. What works is installing a second git and putting it earlier in PATH:

brew install git          # or: brew upgrade git
type -a git               # the first line is the one your shell runs
git --version             # should not say "Apple Git"
/usr/bin/git --version    # still 2.50.1, and that's fine

On this machine type -a git lists /opt/homebrew/bin/git first and /usr/bin/git second. That order is what decides which git you get. brew install git adds a second git and leaves Apple's in place, so if Homebrew's directory isn't before /usr/bin in your PATH, you keep getting 2.50.1. MacPorts (sudo port install git) works the same way. git-scm.com no longer links a standalone macOS installer. The last one stopped at 2.33.0 in 2021.

Scheduled jobs are a separate problem. launchd starts jobs with a PATH of /usr/bin:/bin:/usr/sbin:/sbin (I measured this in launchd plist environment variables), so a job that just calls git gets Apple's 2.50.1. My own wrappers put /opt/homebrew/bin first, so the weekly job in git auto-commit from cron runs Homebrew's git. That git turned out to be 2.54.0, two releases behind, because brew update doesn't upgrade anything (see brew update vs brew upgrade). It missed 11 of the 30 probes, including the sideband masking.

Building from source is quick but has one new snag. On this M4 Mac mini, make -j8 on the 2.56.0 tarball failed at the very end with cargo: command not found. Since 2.55, Rust is on by default, and git 3.0 will require it. Adding NO_RUST=1 fixed it. Each run compiled about 570 files in 10 to 11 seconds of wall time with -j8. The same release notes say git 3.0 will also switch git init's default branch to main. Every build I tested, 2.56.0 included, still creates master.

FAQ

How do I update git on my Mac?

Install a newer git with Homebrew (brew install git, or brew upgrade git if you already have it) and make sure /opt/homebrew/bin comes before /usr/bin in your PATH. Then run type -a git: the first path listed should be Homebrew's, and git --version should no longer say Apple Git. Leave /usr/bin/git alone. It belongs to the Command Line Tools and stays at version 2.50.1.

Why does git --version still say Apple Git after brew install git?

Homebrew installs git to /opt/homebrew/bin/git (or /usr/local/bin/git on Intel Macs). It doesn't replace /usr/bin/git. If /usr/bin is earlier in your PATH, or a launchd job runs with launchd's default PATH of /usr/bin:/bin:/usr/sbin:/sbin, you still get Apple's 2.50.1. Add Homebrew's shellenv line to your shell profile, open a new terminal, or call git by its full path in scripts.

Is the git that ships with macOS a security risk?

Apple Git-155 is git 2.50.1, which includes the July 2025 security fixes, and the git project hasn't published a security advisory since then. What it doesn't have is git 2.55's default masking of terminal control sequences sent by a remote (the issue described in CVE-2024-52005). In a test, 2.50.1 passed all 4 escape sequences from a remote hook through to the terminal, while 2.56.0 masked the 2 that weren't color codes.

Method: on October 11, 2026 I ran the same 30-probe script (probe.sh) on a Mac mini M4 (Mac16,10) running macOS 26.4.1 against /usr/bin/git 2.50.1 (Apple Git-155, Command Line Tools 26.5), Homebrew git 2.54.0, and git 2.56.0 built from the kernel.org tarball (SHA-256 checked against kernel.org's list) with NO_GETTEXT=1 NO_RUST=1. Each run used a fresh repository with a local bare remote, GIT_CONFIG_GLOBAL=/dev/null and GIT_CONFIG_NOSYSTEM=1. The probes came from the "UI, Workflows & Features" sections of the 2.51.0 to 2.56.0 release notes, and the 157 and 301 counts are bullet counts from those notes. One probe (blame --diff-algorithm) exited 0 on 2.50.1 but I didn't check whether it changed the output, so I count it as neither working nor failing. I didn't test Intel Macs, MacPorts, or anything that needs a network remote such as the HTTP 429 handling. The scripts and per-git results are in research/update-git-mac-raw, and I deleted the /tmp build and test directories afterward.