Purpose of isogit-lfs

[ronaldtse]

This is purely for historic reasons on why we need this library.

Paneron uses a package to access Git, called isomorphic-git. However, this package does not support Git-LFS.

However, we need to provide Paneron with Git-LFS support. There is an existing issue on isomorphic-git's repo about this:

• Git LFS support isomorphic-git/isomorphic-git#1375

@strogonoff tried out some code from there, modified/updated it and packaged into this current repo.

The initial steps are listed as this repository's issues:

• Support authentication #1
• Support LFS upload #2
• Test against GitHub LFS implementation #3

[ronaldtse]

This is for @s4birli

[ronaldtse]

Expectations of @strogonoff :

Or should it provide another object command like readLfsBlob that can be used when walking the tree.

From end user perspective, I believe there are two typical uses as far as reading LFS data goes:

• Read a blob (possibly at a specified oid). A separate function like readLfsBlob() could work really well actually, matching the readBlob() API and just returning a blob. No need to fetch in parallel or worry about tainting the working directory in this case.
• Retrieve blobs matching some arbitrary pattern (dependent on UX needs at runtime) into the working directory. A list of object paths would be built for a single batch request, but as @mojavelinux’s pointed out the resulting state of the working directory might confuse other APIs. There’s also the unpleasant race potential, I imagine. Seems both trickier to implement and less essential.

As to adding objects, it’s more difficult to mimc the existing API but a low-level helper function like lfsUpload({ filepath, oid, ... }) could work. One could call it with current oid after adding & committing a file, for example.

Agreed that the behavior of fetching all LFS files matching .gitattributes patterns would rarely be welcome from end application performance standpoint. Actually, personally I’d be fine if IsoGit ignored .gitattributes altogether, and left it to the programmer to decide when use low-level LFS functions.

[strogonoff]

To be clear, that was a discussion on Isomorphic Git core, this is a reusable package and proposed API somewhat changed.

…

On 27 Nov 2021, at 5:18 AM, Ronald Tse ***@***.***> wrote:  Expectations of @strogonoff : Or should it provide another object command like readLfsBlob that can be used when walking the tree. From end user perspective, I believe there are two typical uses as far as reading LFS data goes: Read a blob (possibly at a specified oid). A separate function like readLfsBlob() could work really well actually, matching the readBlob() API and just returning a blob. No need to fetch in parallel or worry about tainting the working directory in this case. Retrieve blobs matching some arbitrary pattern (dependent on UX needs at runtime) into the working directory. A list of object paths would be built for a single batch request, but as @mojavelinux’s pointed out the resulting state of the working directory might confuse other APIs. There’s also the unpleasant race potential, I imagine. Seems both trickier to implement and less essential. As to adding objects, it’s more difficult to mimc the existing API but a low-level helper function like lfsUpload({ filepath, oid, ... }) could work. One could call it with current oid after adding & committing a file, for example. Agreed that the behavior of fetching all LFS files matching .gitattributes patterns would rarely be welcome from end application performance standpoint. Actually, personally I’d be fine if IsoGit ignored .gitattributes altogether, and left it to the programmer to decide when use low-level LFS functions. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[ronaldtse]

This module is now functional. Thank you @strogonoff !