Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GitHub’s Large File Storage is no panacea for Open Source

medium.com

Post reply on HN
Print view View original

61–66 of 66 posts

Re: GitHub’s Large File Storage is no panacea for Open Source

#61

Post by alkonaut »

icebraining wrote: post #43
nkurz wrote: post #14

This seems like an odd problem, but I'm not as familiar with Git as I should be. Is there not a reasonable way to download only the most recent version of these large binary files on the initial request, and then download the historical versions only in the (likely very rare) case that the user actually wants to use them? This would seem more useful in this case than hoping that binary diffs the repository small enou…

If you're talking about binary files merged into Git itself (not Git LFS, which is a separate mechanism), you can use "git clone --depth " to get only the latest revisions of the tree, and then use "git pull --unshallow" if you need to fetch the rest of the history.

Can I do that automatically so that only binaries are fetched shallow, and text is fetched deep? Otherwise it's not very useful.

Re: GitHub’s Large File Storage is no panacea for Open Source

#62

Post by icebraining »

alkonaut wrote: post #61
icebraining wrote: post #43

Earlier quoted context omitted.

If you're talking about binary files merged into Git itself (not Git LFS, which is a separate mechanism), you can use "git clone --depth " to get only the latest revisions of the tree, and then use "git pull --unshallow" if you need to fetch the rest of the history.

Can I do that automatically so that only binaries are fetched shallow, and text is fetched deep? Otherwise it's not very useful.

My best guess would be to keep the binaries in a submodule, then after fully cloning the main repo, you would fetch the binaries with "git submodule update --init --depth 1".

Re: GitHub’s Large File Storage is no panacea for Open Source

#63

Post by sytse »

At GitLab we're working to support LFS. Initial support might or might not work with forks. As now with our Git Annex support storage will be free with a soft limit of 10GB of disk space per project (includes Git, Git Annex and Git LFS data) and there is no bandwidth limit. It will work with public and private projects (both are free).

Re: GitHub’s Large File Storage is no panacea for Open Source

#64

Post by SwellJoe »

paulddraper wrote: post #50
SwellJoe wrote: post #33

Earlier quoted context omitted.

OK, those are maybe a little vicious, and probably not entirely fair. Still, the implication of not being able to fork a whole project from github if you use LFS is a pretty big deal.

I'd hate to see the blog post you call vicious. Does it need f-bombs? Death threats? I think what you mean is that it is not unjustifiably vicious.

It's a little rough, and I wouldn't have been so harsh (my vitriol has faded quite a bit with age). But, having been an open source software developer and running companies based on open source for many years, I am kinda tone deaf to what constitutes "vicious" for folks that aren't accustomed to nerds getting ornery. I'm not defending it...I think the article would have been more eff with less vitriol and more examples of why this behavior is dangerous and past examples of when seemingly non-evil companies have done evil things, whether intentionally or not.

But I didn't write the article. I was just kinda jumping on the "hey Github could potentially do shitty things if we aren't careful" bandwagon. I'm definitely not anti-Github. I think they've built a great product. I'm a paying customer with private repos.

Re: GitHub’s Large File Storage is no panacea for Open Source

#65

Post by jumpwah »

Vendan wrote: post #18
jumpwah wrote: post #11

Earlier quoted context omitted.

Except that's not a "pull request".

Except it is. Just cause github does pull requests differently doesn't mean you can't do pull requests in pure git. Remember, git came before github.

> Remember, git came before github.

That's exactly my point. Using a "request-pull" instead of a "pull-request" will probably mean you can do this git-lfs thing with it. My understanding was that it was not working with "forked" repositories, which you need to have to make a "pull request". To make a "request pull" (or to just send a patch file), you don't need to "fork". ;)

Re: GitHub’s Large File Storage is no panacea for Open Source

#66

Post by pbiggar »

SwellJoe wrote: post #55
pbiggar wrote: post #48

Earlier quoted context omitted.

Its not that I believe good forever, but rather that I think it (it being your first comment) was a weird way to take the conversation. Like, why did that even occur to you in this context?

I left some of the early parts of my thought process out of the conversation. My thought process went something like this: "This is a feature that is currently, probably accidentally, causing vendor lock-in for github users, as there is no easy way to take a project in its entirety back out of github, if it has enabled this feature. That kind of lock-in has been used in the past, by vendors across a wide spectrum, fo…

I see. Yes, lock in has been used for evil in the past.

I thought the OP noted that MS also offers git+LFS (and for free)!

Post reply on HN