I suspect setting up the free LFS reference/test server[1] that GitHub provides would have taken less time than writing this post complaining that GitHub isn't free enough.
GitHub’s Large File Storage is no panacea for Open Source
41–50 of 66 posts
Re: GitHub’s Large File Storage is no panacea for Open Source
#42I suspect setting up the free LFS reference/test server[1] that GitHub provides would have taken less time than writing this post complaining that GitHub isn't free enough. 1: https://github.com/github/lfs-test-server
This being a test server implementation probably indicates that it is not meant to be run in production environment.
Re: GitHub’s Large File Storage is no panacea for Open Source
#43This 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.
Re: GitHub’s Large File Storage is no panacea for Open Source
#44This 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…
Also not very well versed in git, but my understanding is that there is a way to clone a repo to only include latest revisions, but that this limits usage of git. I believe that fixing this was an area of active development a few months ago, its possible it already landed.
Shallow clones are the term. It used to be that you couldn't pull remote changes or push local changes to/from a shallow clone, but that was fixed with v1.9 (early 2014). I'm not sure how LFS interacts with shallow clones though, as it's really a separate system that works in tandem with git more than a part of git itself.
Re: GitHub’s Large File Storage is no panacea for Open Source
#45In the interest of not propagating this common misconception: "The main problem with Git is that binary files are stored “as is” in the history of the project, so that every single revision of a new binary file (even if just a single byte has changed) is stored in full. [...] On the other hand, source files being mostly text, they are more intelligently handled and typically only differences between revisions are sto…
This. Unlike many other systems, compression in git has nothing to do with commit order or file types or really anything VCS related. The way delta chains work in git are ingenious and transparent.
The problem is that "binaries" are large amounts of data with high entropy.
Re: GitHub’s Large File Storage is no panacea for Open Source
#46The post seems hyperbolic. I'd love to hear GitHub's rebuttal.
I am the author and yes this was very much unapologetically hyperbolic. At least it got the conversation started.
I don't think you needed paragraphs like "My guess is that some high-level greedy marketing dickwad, completely unaware of the asinine implications of his brilliant idea, signed off on this dumb-as-a-bag-of-rocks pricing model. He then directed the grunts to somehow implement his grand vision on GitHub’s servers. That’s when shit started to hit the fan." ... to get the conversation started. Your other points were sensible and lucid. This was a distraction and had the paradoxical effect of making me more sympathetic to github. The same looks to be true of other posters in this thread.
If you were consciously choosing to take a hyperbolic tone, can I ask if you might reconsider that decision in future posts? Or at least concretely test your idea that calling people "dickwads" and "grunts" gets you more traction.
I appreciated you raising the bandwidth question, and comparing it with other services. You made a good argument. Thank you!
Re: GitHub’s Large File Storage is no panacea for Open Source
#47> Case in point: if a very popular Github repository (such as the one for the Linux kernel) decided to start using LFS for some of their files, they would instantly alienate all of their users. They would no longer be able to properly fork the project, or even clone it to get its binary files stored via LFS. Nobody would be able to send a pull request to Linus as a result without considerable effort. Odd example. Lin…
They still use pull requests, though, just in the form of email-based ones. https://git-scm.com/docs/git-request-pull
Sure. With git-fu and enough emails, you can replicate anything done in GitHub.
I'm just saying it's a very odd choice for an example of GitHub screwing over workflows.
Re: GitHub’s Large File Storage is no panacea for Open Source
#48Earlier quoted context omitted.
GitHub has added features, and made their product better for their customers, but have not yet made it possible to use from everywhere on their platform. Perhaps that is a big deal (I don't use LFS and until recently neither did anyone else), but it's a far cry from what you said in your original comment, such as "I do believe it is foolish to assume that the github we know today will be the github of tomorrow." They…
No, of course not. I have nowhere said github is evil. I've said it would be foolish to believe they never will be, because we have seen on a number of occasions that good companies turn bad (with varying definitions of "good" and "bad") when given sufficient monetary motivation to do so. SourceForge is the best past analog for github, and I think it's worth learning from history. SF.net didn't start out evil and unt…
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?
Re: GitHub’s Large File Storage is no panacea for Open Source
#49Earlier quoted context omitted.
Yeah I am assuming OP doesn't realize that patches are sent to the Linux kernel through emails.
I do, actually. I just noticed that there was a large Kernel git repo hosted on Github, and figured it would make a good example of a large, popular repository. I'm not surprised Linus is not actually using Github, so my bad for not stressing that this was more hypothetical than meant as a statement of fact.
There are literally thousands of uber-popular projects that are deeply integrated with GitHub. I recommend choosing one of those for an example.
Line NodeJS or something.
Re: GitHub’s Large File Storage is no panacea for Open Source
#50Earlier quoted context omitted.
Really? These aren't vicious? "My guess is that some high-level greedy marketing dickwad, completely unaware of the asinine implications of his brilliant idea, signed off on this dumb-as-a-bag-of-rocks pricing model." "All the marketing material pimping GitHub’s LFS support [...]. I do not believe this is unintentional." "This is completely batshit. The side effect of this pernicious, greedy pricing model is to [...]…
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.