Yes! Bringing us all one step closer to the whiysi (we host it you store it) dev paradigm. Bravo!
Announcing Git Large File Storage
21–30 of 167 posts
Re: Announcing Git Large File Storage
#22So basically it's git-annex, but tied to GitHub. http://git-annex.branchable.com/
Yeah, that was exactly my feeling.
"Not invented here" much?
Re: Announcing Git Large File Storage
#23So basically it's git-annex, but tied to GitHub. http://git-annex.branchable.com/
As far as I can tell, less flexible (far less) then annex but it can be made very seamless to the user (no/few special commands and lfs tracking by filemask.)
I would think bridging the gap in annex to track by file pattern would be easy but a lot of people might prefer not to know how to make annex go. So using simplicity as differentiator.
Re: Announcing Git Large File Storage
#24Can't wait too see what Linus got to say about this. I suppose he got an arguably better solution to the problem?
Re: Announcing Git Large File Storage
#25This 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…
That's an interesting point I hadn't considered before. Git, as a distributed vcs, takes the position that everyone can edit all files, and rare conflicts can be managed easily because changes are relatively small and diffable.
But these assumptions break down with binary assets. Changes are not small, they typically change entire files at once. They're also not diffable. As a result, conflicts are not rare, they're common, and impossible to resolve for both parties. That's why locking or "checking out" certain files is a needed feature, so changes are ordered strictly linearly -- a graph structure doesn't work.
Re: Announcing Git Large File Storage
#26The "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 hav…
The filter-by-filetype can be replace by small script that augments git: http://git-annex.branchable.com/forum/help_running_git-annex...
Re: Announcing Git Large File Storage
#27This 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…
That's an interesting point I hadn't considered before. Git, as a distributed vcs, takes the position that everyone can edit all files, and rare conflicts can be managed easily because changes are relatively small and diffable. But these assumptions break down with binary assets. Changes are not small, they typically change entire files at once. They're also not diffable. As a result, conflicts are not rare, they're…
> They're also not diffable.
I think that really is a problem with the diff tools, not the format itself. This is why both Mercurial and git allow you to pick special diff and merge tools per filename extension.
Re: Announcing Git Large File Storage
#28> 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.
I'm having trouble seeing where a 1GB/month quota in any way meshes with "large file" support. The free tier is basically "test out the API, don't even think about using it for real".
Re: Announcing Git Large File Storage
#29So basically it's git-annex, but tied to GitHub. http://git-annex.branchable.com/
(Not a git-annex user here). I suppose functionally, these two are similar. But the use case is different. git-annex seems to be more for managing files and making sure they don't disappear on you. GitHub's new thing is for keeping track of larger objects inside your git project efficiently. Basically, yeah, you can use git-annex to store the PSD, the audio samples, the promo video, etc. but wouldn't it be nice to have it all tied in with your normal project workflow?
Re: Announcing Git Large File Storage
#30Has someone had a closer look and can say how this compares to Git-Annex?
This and git-annex (and git-fat and others) use the same basic architecture of storing links in Git and schlepping the binaries around separately.
Git-annex renames binaries with their SHA256 hashes, puts them in a .git/annex/ dir, and replaces files in the working dir with symlinks. Git-LFS seems to use small metadata pointer files (SHA256 hash, file size, git-lfs version) instead of symlinks. Not sure whether the files reside in something like the .git/annex/ dir; I'm guessing the do or there wouldn't be those pointer files.
You can clone a repo without having to download the files.
With git-annex you can sync between non-bare and bare repositories without having a central server. Git-LFS seems to have a separate server for binaries. It looks like it may act like a git-annex special remote rather than git-annex's usage of synced/master branch.
Git-annex repos share information about the locations of annex files, how many repos contain a given file, etc. You can trust and un-trust repos. It doesn't look like Git-LFS offers this.
Git-LFS has a REST API. I'm using an old version of git-annex so I can't say if it does (I think it does).
Git-LFS is written in Go, git-annex is Haskell.
Git-LFS is a GitHub project. GitHub will offer object hosting.
Update: clarity, speling, added a bullet point.