This looks really interesting. You basically trade the ability to have diffs (nearly meaningless on binary files anyway) for representing large files as their SHA-256 equivalent values on a remote server. What will be interesting is to see whether GitHub's implementation of LFS allows a "bring your own server" option. Right now the answer seems to be no -- the server knows about all the SHAs, and GitHub's server only…
If the extension is open-source, you could probably build your own server implementation and fork the extension to change what server it contacts.
Announcing Git Large File Storage
11–20 of 167 posts
Re: Announcing Git Large File Storage
#12> Every user and organization on GitHub.com with Git LFS enabled will begin with 1 GB of free file storage and a monthly bandwidth quota of 1 GB.
Does this mean that with the free tier I can upload a 1GB file which can be downloaded at most once a month? Even a small 10MB file, which fits comfortably in a git repo, could be downloaded only 100 times a month. Maybe they meant 1TB bandwidth?
Re: Announcing Git Large File Storage
#13The "filter-by-filetype" approach used here is going to work a lot better for mixed-content repositories than git-annex, which doesn't have that capability built-in (to my knowledge).
git-annex has been great for my photo collection (which is strictly binary files). It lets me keep a partial checkout of photos on my laptop and desktop, while replicating the backup to multiple hosts around the internet.
At work we have a bunch of video themes that are partially XML and INI files and partially JPG and MP4. LFS would work great for us, except we don't use github (we don't have a need for it.) It looks like this is going to be very simple for that kind of workflow.
Just yesterday HN user dangero was looking for this exact sort of thing, large file support in git that didn't add too much complexity to the workflow: https://news.ycombinator.com/item?id=9330125
Re: Announcing Git Large File Storage
#14This looks like it misses the mark a bit.
As anyone who's worked on project with large binary files(the docs assume PSDs) you need to be able to lock unmergeable binary assets. Otherwise you get two people touching the same file and someone has to destroy their changes. That never makes anyone happy.
It's also unseen how good the disk performance is. These two areas are the reason why Perforce is still my go-to solution for large binary files.
Re: Announcing Git Large File Storage
#15This looks really interesting. You basically trade the ability to have diffs (nearly meaningless on binary files anyway) for representing large files as their SHA-256 equivalent values on a remote server. What will be interesting is to see whether GitHub's implementation of LFS allows a "bring your own server" option. Right now the answer seems to be no -- the server knows about all the SHAs, and GitHub's server only…
[deleted]
[deleted]
Re: Announcing Git Large File Storage
#16So basically it's git-annex, but tied to GitHub. http://git-annex.branchable.com/
Re: Announcing Git Large File Storage
#17> Every user and organization on GitHub.com with Git LFS enabled will begin with 1 GB of free file storage and a monthly bandwidth quota of 1 GB. Does this mean that with the free tier I can upload a 1GB file which can be downloaded at most once a month ? Even a small 10MB file, which fits comfortably in a git repo, could be downloaded only 100 times a month. Maybe they meant 1TB bandwidth?
I would suspect the point is rather that you have a bunch of megabyte range files, and you rarely update them and don't have to sync. But for most workflows this feature seems targeted at, the free tier seems insufficient.
Re: Announcing Git Large File Storage
#18Has someone had a closer look and can say how this compares to Git-Annex?
Re: Announcing Git Large File Storage
#19This solves a real problem, but I can't help but feel it is a band-aid hack. The main fundamental advantage (vs implementation quirks of git) I can see is that these files are only fetched on a git checkout. But (of course) this breaks offline support, and it requires additional user action. Wouldn't it have been fairly easy to build exactly the same functionality into git itself? "Big" blobs aren't fetched until the…
I have a feeling the decision for how to arrange, as a separate thing, is likely to feed the monetization component. Particularly if it's limited to using GitHub's storage.
Specs are open, there's an open server implementation. It might be easiest to set it up with github, but if it catches on, I expect implementations will be readily available from all github-like platforms and as stand-alone.
Re: Announcing Git Large File Storage
#20This looks like it misses the mark a bit. As anyone who's worked on project with large binary files(the docs assume PSDs) you need to be able to lock unmergeable binary assets. Otherwise you get two people touching the same file and someone has to destroy their changes. That never makes anyone happy. It's also unseen how good the disk performance is. These two areas are the reason why Perforce is still my go-to solut…
Mercurial has largefiles and locking too:
http://mercurial.selenic.com/wiki/LargefilesExtension
http://mercurial.selenic.com/wiki/LockExtension
Like other people have noticed, you can have the good parts of a DVCS and the good parts of a CVCS. It doesn't have to be either-or:
https://blogs.janestreet.com/centralizing-distributed-versio...
http://bitquabit.com/post/unorthodocs-abandon-your-dvcs-and-...