RE: [Question] Alternative to git-lfs under go
On September 17, 2018 6:02 PM, Jonathan Nieder wrote:
Show 36 quoted lines
> Randall S. Becker wrote:
> > On September 17, 2018 3:28 PM, Jonathan Nieder wrote:
> >> Randall S. Becker wrote:
>
> >>> Does anyone know whether it is practical to rework git-lfs under a
> >>> language other than "go"? GCC is not even close to being possible to
> >>> port to my NonStop platform (may have tried, some have died - joke -
> >>> trying). I would like to convert this directly to C or something
> >>> more widely portable. Is there a protocol doc out there I can reference?
> >>
> >> Can you say more about the context? You might like
> >>
> >> git clone --filter=blob:limit=512m <repo>
> >>
> >> which tells Git to avoid downloading any blobs larger than 512
> >> megabytes until you know they need them. See
> >> Documentation/technical/partial-clone.txt
> >> for more details.
> >
> > Sorry, I was not clear. I am not having issues with large files or
> > blob limits. Members of my community wish to use Git LFS support on
> > their enterprise git servers, so as platform maintainer for git on
> > NonStop, I am trying to accommodate them. The stumbling block is that
> > "Go" language will not port to the platform.
>
> Thanks. Then the answer is "no": there has not been a reimplementation of
> Git LFS in another language, and my advice to someone pursuing that would
> be to use the native Git feature described above instead (or to get Go
> working on their platform).
>
> If I'm reading
> https://github.com/git-lfs/git-lfs/blob/master/CONTRIBUTING.md
> correctly, the preferred way to contact the Git LFS maintainers is using
> Github's issue tracker.
>
> Thanks and sorry I don't have better news, Jonathan
It is the interoperability with existing Git LFS repositories that my community is requesting, not specifically any file size issues. Some want the locking function. The API looks fairly straight forward and I suspect a complete reimplementation will take less of my time than trying to get GO to actually run on the platform. Cross-compilation might be an option, but that's likely a tricky proposition that has not worked in the past - the issue there is that cross compilation requires Windows and Cygwin, which make configure rather confused and so far, not workable. Neither GCC nor GNULIB build completely in port attempts. So the answer is "NO". ☹
Randall S. Becker <rsbecker@nexbridge.com>