Repository navigation
git-lfs support #2812
Description
Our current bug #2809 (our broken pre-push hook support) led me down the rabbit hole of "what else is required to properly support git-lfs in gitui.
We are looking at basically three things:
- properly run pre-push hook (thats Pushing throws pre-push hook error on repository with LFS. #2809)
- hook into filter logic and run them on all checkout-like operations (smudge)
- hook into filter logic and run them on all worktree->index operations (clean)
Now libgit2 exposes an API to hook into filters but git2-rs does not expose this right now (open issue).
Since our end goal is to be libgit2 independent I call out whats needed to do this all using gitoxide:
- we need to migrate all our git-checkout locations to gitoxide
- migrate all worktree->index operations to gitoxide
use gitoxide machinery to hook into filters(turns out gitoxide will already invoke filters for us)forward filter logic via shellout (git-lfs clean,git-lfs smudgeorgit-lfs filter-process)- finally we support basic git-lfs
- add support for more file locking relevant lfs features via hooks:
post-checkout,post-merge,post-commit
This issue is more of an epic, I would love to see contributions to take on individual steps as separate PRs.
cc @Byron @cruessler correct me if I am wrong but from the gitoxide side all this is ready to be used or am I wrong?
Further reading: #1089
Activity
Byron commentedon Dec 18, 2025
Thanks for the summary! Here are my notes:
This will already work as long as you only checkout individual files, see
filter_pipeline.This will also work as long as checkins are per-file, see
filter_pipeline.I don't understand where this requirement is coming from, I am just missing a hint on the feature that this supports.
My potshot here is that in theory, as filters are invoked by
gituion a per-file basis, pre- and post- filter hooks are naturally present.Standard Git filters are naturally supported and invoked, there is no extra action needed unless
gituiwants to support git-lfs specifics that aren't covered by standard Git filters.I think the crux here would be that
gitoxidehas no mechanism of doing a worktree checkout yet, and the one that's planned will be a brute force "apply the changes that are needed to turn tree A into tree B", overwriting anything in its path. It will be very much on the plumbing side of things. GitButler needs such a primitive as it does the analysis on what to do with changed or untracked files that would be in the way. Something like it would have to be ported to over then, while just adhering to the 'Git-style' of doing this (i.e. force, non-force, for starters).Besides the checkout, there are weaknesses when interacting with the
.git/index- it's very much expert mode and plumbing level. But GitButler uses that to get what it needs, so it can be done.extrawurst commentedon Dec 18, 2025
I guess I was under the assumption that gitoxide would make me implement the filter logic myself just like libgit2.
That is awesome. Does it support both smudge/clean and the more modern filter-process?
I understand but if we checkout a worktree on a per-file-basis it should already work? Does that have some specific downsides other than being more laborious?
Byron commentedon Dec 18, 2025
Yes, if more modern means the single-invocation ones. For all I know, filters are fully supported.
It's implemented as the caller choosing a direction - convert data for storage in Git, or for placement in the worktree.
I wouldn't recommend it - the worktree is holy and needs a lot of care. If a
gixclient was to implement this 'properly', they would write the implementation thatgixshould have had in the first place. And everything below 'properly' really shouldn't be unleashed into this world 😁. Trust me 🙇♂️.With that said, when
gix cloneis used,gixwill checkout the worktree, but it can only do it safely (and very quickly) because it has exclusive access to a known-to-be-empty directory. When the user also has access to it, it gets way more involved.With that said, all the code to do it 'properly' is there already, it just needs to be combined and tested to death to not be worse than Git (or better: implement all the knowledge that Git gathered in its 20 years or so. This is what makes it so dangerous - treacherously simple, and full of mines right next to foot guns.)
Yeah, so ensuring its correctness is certainly the most time consuming part, along with implementing it in single-threaded and multi-threaded mode to have another reason to exist (why do it if you can't make it better/faster).
Thanks for nerd-sniping me into analysing this more than I have ever consciously done 🙏.
extrawurst commentedon Dec 18, 2025
@Byron is there a gitoxide issue to track for proper
git checkoutsupport? For now this seems like the big thing this is hinging on and what I would wait for first.Byron commentedon Dec 19, 2025
I don't think there is and couldn't find one. But rest assured that I will let you know once that changes.
Right now, there is nobody working on this and when I do, I will only implement the plumbing level version of it, equivalent to
git reset --force. The non-force part would still need to be implemented by the client then, but that should be the easy part.The reason I think it's acceptable to do that for now is that I don't know how to implement this to be library-worthy in
gitoxide, i.e. hit the right tradeoffs between control and ease of use.ViscousPot commentedon Jan 6, 2026
Hey @extrawurst!
I am also looking into supporting git-lfs through git2 for my own application and came across this thread from years ago now that you were part of.
rust-lang/git2-rs#442
It happens to reference this link that is now dead and I was wondering if you remember anything about what it was 🙏🏾
Hoping it's the missing link to making some forward progress on lfs
https://github.com/samlh/gitblob/blob/97a897da973af6b0a5548469fcd5e081936074cd/src/main.rs#L255-L276