4 ms·
> tied to GitHub. The protocol is open (https://github.com/github/git-lfs/blob/master/docs/api.md https://github.com/github/git-lfs/blob/master/docs/api.md) an
by bhuga 12y ago
> tied to GitHub.
The protocol is open (https://github.com/github/git-lfs/blob/master/docs/api.md https://github.com/github/git-lfs/blob/master/docs/api.md) and the client additions are open source. There is a reference server implementation at https://github.com/github/lfs-test-server https://github.com/github/lfs-test-server.
edit: added protocol spec
- chimeracoder 12y ago> The protocol is open and the client additions are open source. There is a reference server implementation at https://github.com/github/lfs-test-server https://github.com/github/lfs-test-server. This isn't about this particular instance (Github's LFS), but in general, a "reference implementation" isn't the same thing as having an open protocol. Having a reference implementation without a proper specification means that any other implementations have to re-implement the existing reference implementation, including any bugs. The purpose of a specification is to outline undefined behavior as much as it is to outline defined behavior. That is, the specification says, "these are the portions of the program which you may not rely on". We've seen this happen in some languages in which a particular implementation is either the de facto or de jure standard. Other compilers or interpreters end up having to mimic their bugs when it comes to things like arithmetic overflow/precision errors, because developers have come to rely on the language behaving one way, in the absence of any clear rules telling them otherwise[0]. [0] Not that developers may not rely on things that a specification explicitly tells them not to - there are plenty of examples of this too - but at least then it's possible to say determine either that a particular program will run on any standards-compliant implementation, or that it is implementation-specific.
- bhuga 12y agoYou're right, the protocol is also required. I didn't link to it in my comment, but it is also open and well-defined. I've updated my comment. Thanks!
- rmc 12y agoEmbrace. Extend. Extinguish.
- sytse 12y agoAll GitLab contributors are working on an alternative ending.
- efuquen 12y agoWhy reinvent the same thing? What were the technical deficiencies of git-annex that necessitated this? Or is this NIH syndrome? I think these are all reasonable questions.
- sytse 12y agoGitLab CEO here. It would have been nice if they would have developed this in the open, Joey from git-annex is pretty open minded, maybe we could have prevented another standard.
- Rapzid 12y agoI would have thought that it would have been particularly important for this to have been open to review and critique from the start given GitHub's status and importance to the wider community. Heck, even Microsoft is developing new .Net components in the open. Would have been nice to have had debate on existing solutions to weigh the pros/cons.
- sytse 12y agoThanks Rapzid, I also think that an open process would have lead to a better outcome. I hope GitHub follows up with a rationale for the points Joey mentioned in this thread.
- caust1c 12y agoTo be honest, it doesn't look like they put much additional thought into the problem at all. git-filters are going to be the limiting factor for performance here and depending on your filesize might still cause a considerable slowdown. I would have liked to see a solution with patching git and `sendfile` myself. See my other comment here: https://news.ycombinator.com/item?id=9345242 https://news.ycombinator.com/item?id=9345242