Skip to content

Find git-lfs in the user's PATH instead of hardcoding /usr/local/bin - #2835

Open
mluisbrown wants to merge 2 commits into
git-up:masterfrom
mluisbrown:fix-git-lfs-path
Open

mluisbrown wants to merge 2 commits into
git-up:masterfrom
mluisbrown:fix-git-lfs-path

Conversation

@mluisbrown

Copy link
Copy Markdown
Contributor

Fixes #805.

GitUp only registered its Git LFS filter if git-lfs existed at exactly /usr/local/bin/git-lfs. With Homebrew on Apple Silicon (/opt/homebrew/bin) or MacPorts (/opt/local/bin), the filter was never registered. LFS files were then checked out as pointer files and committed as raw content instead of LFS pointers, with no error.

Changes

  • The lfs filter is now always registered. git-lfs is looked up the first time a file with the filter=lfs attribute is processed, and the result is cached. The lookup searches the login shell PATH (the same approach hooks already use), then falls back to /opt/homebrew/bin, /usr/local/bin and /opt/local/bin. Repositories that don't use LFS never run the lookup.
  • A new check callback returns GIT_PASSTHROUGH if git-lfs can't be found, so LFS files are left as pointer files. This preserves the previous behavior when LFS isn't installed.
  • git-lfs now runs with the login shell PATH, so the git it invokes is the same one the user gets on the command line.
  • The shell PATH lookup moved into a shared static function so the filter can call it without a repository instance. -getPATHUsingShell:error: now wraps it and behaves the same as before.

Testing

  • Added testGitLFSCleanFilter. It checks that adding an LFS-tracked file to the index stores an LFS pointer, and it skips itself if git-lfs isn't installed. I confirmed that it fails against the old code when nothing exists at /usr/local/bin/git-lfs, and that it passes with this change.
  • GitUpKit (macOS) tests: 96 of 97 pass. The only failure is testDateFormatting ("This Monday" vs "Last Monday"), which depends on the current date and fails without this change too.

The wiki currently says git-lfs must be installed at /usr/local/bin/git-lfs, so it should be updated after this is merged.

🤖 Generated with Claude Code

The LFS filter was only registered if git-lfs existed at /usr/local/bin/git-lfs,
so with Homebrew on Apple Silicon (/opt/homebrew/bin) or MacPorts (/opt/local/bin)
LFS files were silently left unfiltered (git-up#805).

The filter is now always registered and git-lfs is resolved lazily, the first time
a file with the lfs filter attribute is processed, from the login shell PATH with
fallbacks to the common install locations. If git-lfs isn't found the filter
passes through, preserving the previous behavior. git-lfs is also run with the
login shell PATH so it uses the same git as the command line.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@greptile-apps

greptile-apps Bot commented Oct 16, 2026 •

Copy link
Copy Markdown

RetriggerView in GreptileConfidence Score: 5/5

[Medium impact] The PR appears safe to merge; no outstanding findings remain.

Summary

GitUp now finds git-lfs through the login shell’s PATH, with standard installation directories as fallbacks.

  • GitUp finds Git LFS in the user's PATH and filters LFS files.

Reviews (2) · Last reviewed commit: "Add deterministic test coverage for the ..." · Reviewed by Greptile

Comment thread GitUpKit/Core/GCRepository-Tests.m Outdated
Extract the lookup into GCFindExecutableInPATH() so it can be tested with a
controlled PATH and fake executables, independent of whether git-lfs is
installed or present at /usr/local/bin. Also ignore directories named like the
tool, which -isExecutableFileAtPath: would otherwise accept.

The real git-lfs test remains as a smoke test.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

git-lfs post commit hook error, but only in app

1 participant