31–40 of 66 posts
There's a lot of assumptions here about GitHub being greedy. I've got no idea how much money it costs GitHub to support Open Source projects, but it must easily be in the millions. I think that by this point GitHub deserves the benefit of the doubt before launching into vicious accusations.
I'm not sure I understand why artifacts can't be stored in a different service - even an S3 bucket, if not a real repository service - and fetched dynamically via a build process. Is there a reason why binary blobs need to be stored directly next to code in order to be versioned?
Also you'd need the necessary LFS server piece on Amazon's side.
Earlier quoted context omitted.
While I don't think github is deserving of "vicious accusations", I do believe it is foolish to assume that the github we know today will be the github of tomorrow. SourceForge.net was once an excellent and trustworthy steward of Open Source software projects. It was predicted by some folks in the free software community that it would not always be the case, and alternatives like Savannah were maintained in order to…
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 [...]…
> 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…
Yeah I am assuming OP doesn't realize that patches are sent to the Linux kernel through emails.
I'm not sure I understand why artifacts can't be stored in a different service - even an S3 bucket, if not a real repository service - and fetched dynamically via a build process. Is there a reason why binary blobs need to be stored directly next to code in order to be versioned?
Aside from a second point of failure, how does this integrate with anything? When you push, what piece of software pushes what where? And who pays?
The idea isn't to shove everything into a storage bucket, but to assemble a toolchain using components that are fit for purpose. Git is fundamentally not fit for purpose as an artifact repository. There are tools that are.
-Eric
Earlier 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.
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 implement a feature in a restricted manner and all of a sudden they're evil?
I'm not sure I understand why artifacts can't be stored in a different service - even an S3 bucket, if not a real repository service - and fetched dynamically via a build process. Is there a reason why binary blobs need to be stored directly next to code in order to be versioned?
The way I understand it, it should be possible, though it's more complicated since they seem to infer the LFS URL from the repo URL by default. So if you wanted to say keep your repo on Github, and store your LFS files on S3, you'd need to explicitly tell git where to write the files. There are configuration values for that. Also you'd need the necessary LFS server piece on Amazon's side.
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.
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…
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 untrustworthy; they started out good. Who's to say github won't do the same?
Shock and horror: commercial company has a paid value add. GitHub is not a charity.
I wouldn't necessarily describe a paid feature that breaks all forking for an entire repository a "value add".
> I honestly couldn’t believe that GitHub would be willing to do something that shortsighted, visibly motivated by greed from the cash they thought they could extract from some of their users. They're a business. C'mon here.