From: Junio C Hamano <gitster@pobox.com>
Date: Mon, 27 Jun 2016 16:09:06 GMT
Subject: Re: [RFC] Native access to Git LFS cache
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.