Git LFS became necessary once my notes started including images and other larger files.

I have been moving those notes into a Git-backed setup where I own the files. Part of that comes from my experience with Evernote. Once I ran into a paywall and still did not have flexible, system-level access to my own notes, I realized I did not want to keep investing in a setup where the files were not really mine.

In that setup, Git LFS matters for a simple reason: some notes include images, and I do not want those assets bloating normal Git history or making the remote repo unnecessarily heavy.

So the goal was straightforward: get git lfs working in Terminal on my 2017 Intel MacBook Pro running Ventura and move on. Part of the reason this mattered in 2026 was that I was turning that old machine into an OpenClaw box, so getting this Git-backed notes workflow working there was useful beyond this one install.

That is not what happened.

brew install git-lfs did not behave like a quick utility install. It started pulling in dependencies, warning about outdated Command Line Tools, and drifting into a much heavier build path than I expected.

I assumed it would finish in 20 to 30 minutes. A few hours later, it was still compiling.

The fix turned out not to be waiting longer. It was realizing that GitHub Desktop had already installed the Git toolchain I needed, including Git LFS.

If you are trying to get Git LFS working on an Intel Mac and Homebrew seems to be taking forever, this may save you some time.

Why Git LFS install got so slow

When I ran:

brew install git-lfs

the install stopped looking small pretty quickly.

A few things stood out:

  • Homebrew pulled in openssl@3
  • it warned that my Xcode Command Line Tools were outdated
  • it classified the machine as a Tier 2 setup
  • the process moved into source compilation

At that point, the output stopped looking like “install one small utility” and started looking more like toolchain maintenance. That was the point where I stopped treating this as something I should patiently wait out.

What seemed to be happening was not that git-lfs itself was unusually big. The real problem was that the support path around the install on this machine had become the bottleneck.

This matters because the machine was not fully unsupported. A 2017 Intel MacBook Pro on Ventura still works, but it no longer sits in the most well-supported part of the Homebrew matrix, especially once outdated Command Line Tools enter the picture.

The turning point

I briefly considered more dramatic fixes, including changing package-manager strategy. But that would have been solving the wrong problem.

I did not actually need to fix Homebrew first. I needed a working git lfs command in Terminal so I could keep using a Git-backed notes workflow with image assets on this Mac.

Instead of asking, “How do I force this install to finish?” the better question became, “What is the shortest path to a working Git LFS setup on this machine?”

Using GitHub Desktop’s bundled Git toolchain

GitHub Desktop already ships with its own Git binaries.

It also includes git-lfs, just not in the most obvious place.

On my machine, the paths were:

Git

/Applications/GitHub Desktop.app/Contents/Resources/app/git/bin/git

Git LFS

/Applications/GitHub Desktop.app/Contents/Resources/app/git/libexec/git-core/git-lfs

So instead of waiting on Homebrew, I pointed Terminal at the Git toolchain GitHub Desktop had already installed.

I could also have downloaded the official Git LFS binary directly from the project site. But in this case GitHub Desktop was simpler because I already use it on this older Intel MacBook Pro. Keeping Git and Git LFS inside the same bundled toolchain felt like the cleanest way to avoid mixing installations.

I added these environment variables:

export PATH="/Applications/GitHub Desktop.app/Contents/Resources/app/git/bin:$PATH"
export GIT_EXEC_PATH="/Applications/GitHub Desktop.app/Contents/Resources/app/git/libexec/git-core"

Then I restarted the shell and checked:

git --version
git lfs version

That worked.

No separate Homebrew git-lfs install was needed.

The important part was keeping the toolchain consistent: use GitHub Desktop’s Git, and let it find its matching Git LFS support instead of mixing pieces from different installs.

I could have kept waiting, or gone looking for another standalone binary. But GitHub Desktop was already installed, and the binaries I needed were already sitting on the machine.

So the shortest practical path was:

  • stop waiting on the heavy Homebrew path
  • reuse the installed Git toolchain
  • make Terminal use it correctly
  • keep Git and Git LFS coming from the same source

That was simpler than cleaning up the whole package-manager situation just to get one command working.

The real lesson

The useful realization here was that I had started solving the wrong layer of the problem.

I thought I needed to finish installing one small utility. In practice, I needed a working Git and Git LFS toolchain for a notes workflow built around owning my own files.

Once Homebrew drifted into a heavier source-build path, the smarter move was not to become more patient. It was to route around the bottleneck using tooling that was already on the machine.

In this case, GitHub Desktop already had the answer.

This is a practical workaround, not necessarily the forever answer for every Mac. But if GitHub Desktop is already installed and the immediate goal is simply to get git lfs working without sitting through a long build spiral, it is a very reasonable shortcut.