Re: [RFC] Native access to Git LFS cache
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Jun 27, 2016, 16:09 UTC
- Message-ID
- <xmqqmvm6bom5.fsf@gitster.mtv.corp.google.com>
- In-Reply-To
- <1467005913-6503-1-git-send-email-larsxschneider@gmail.com>
larsxschneider@gmail.com writes:
> Unfortunately that fix helps only with cloning. Any local Git operation > that invokes the clean/smudge filter (e.g. switching branches) is still > slow.
Do you know where the slowness comes from? Does Joey's new clean/smudge interface help GitLFS?
You are not likely to get anything that knows that a blob object may be named as anything other than SHA-1("blob <len>" + <contents>) to Git core. The remote-object-store idea that was floated by Peff and Christian started running with at least maintains that object naming property and has a better chance of interacting better with the core, but LFS, Annex or anything that would not preserve the object naming would not.
Personally, I view a surrogate blob left by LFS in the tree object and filtered via clean/smudge a "smarter" kind of symbolic link that points outside what Git controls. The area outside what Git controls is left to be managed by whatever the add-on does; Git shouldn't even be aware of how they are structured and/or managed.