Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Announcing Git Large File Storage

github.com

Post reply on HN
Print view View original

61–70 of 167 posts

Re: Announcing Git Large File Storage

#61

Post by zipperhead »

res0nat0r wrote: post #51
fragmede wrote: post #35

Earlier quoted context omitted.

> (Not a git-annex user here) You could at least read the examples on the git-annex page[1] before passing judgement that the use cases are at all different (they're not). Instead of using a new 'lfs' command that ties you to GitHub, you use an 'annex' command (along with a few others). Git-annex does just fine "keeping track of larger objects inside your git project efficiently", and is no more divorced from your no…

I tried git-annex a couple of times to sync my 2 OSX and linux based computers at my house and play around. It wasn't the easiest thing to get setup and working and I couldn't get one of the OSX hosts to work at all. I'm sure this will be much easier to use for the end user like other github products and will "just work" out of the box.

As a counterpoint, I just set up git-annex and sync'd a couple of local servers plus a remote server, with no issues, by following along in the walkthrough. Granted, it's not exactly an out-of-the-box setup, like say, syncthing, but it wasn't anything overly difficult.

Re: Announcing Git Large File Storage

#62

Post by s73v3r »

efuquen wrote: post #56
azernik wrote: post #41

Earlier quoted context omitted.

This is also free software, and you can also use your own server.

I think the question is why did they role their own solution when there was one already an open and freely one available. If it wasn't suitable in some way I would really like to know why.

If git-annex really worked well, and was easy to use, I imagine there'd be much more uptake of it.

Re: Announcing Git Large File Storage

#65

Post by infogulch »

Oompa wrote: post #59
infogulch wrote: post #38

Earlier quoted context omitted.

Most binary assets are compressed. Diff tools can't work with compressed assets; you'll have to decompress before diffing. Sometimes they also include checksum information which would invalidate any attempt to merge. How far do you take the decompression? For raster images, you'll probably have to decompress all the way to bitmap because the same image could have multiple completely different binary representations i…

Showing diffs for binary assets doesn't need to include things like "brightness 1%". GitHub currently supports image diffs, they're simply displayed side by side, or on top of each other.

This isn't about showing diffs, it's about merging diffs from two separate changes. The best github can do for that right now is let you choose which one you want to keep, it doesn't let you stack changes to keep work from both committers. For that's you need fine grained explanatory stackable diffs.

Re: Announcing Git Large File Storage

#66

Post by IgorPartola »

fragmede wrote: post #35
IgorPartola wrote: post #29

Earlier quoted context omitted.

(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 ha…

> (Not a git-annex user here) You could at least read the examples on the git-annex page[1] before passing judgement that the use cases are at all different (they're not). Instead of using a new 'lfs' command that ties you to GitHub, you use an 'annex' command (along with a few others). Git-annex does just fine "keeping track of larger objects inside your git project efficiently", and is no more divorced from your no…

I did read the use cases and the main pitch. I guess these don't highlight very well how it actually functions. Can I do "git add large.mp4 && git commit" the way I do now?

Re: Announcing Git Large File Storage

#67

Post by sytse »

icebraining wrote: post #7
jxf wrote: post #4

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…

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. That's exactly what git-annex does. Except it can host on your own servers, or S3, or Tahoe-LAFS, or rsync.net, etc. And it's free software. And it supports multiple servers for the same repo, so you have redundancy. Adding an S3 remote is just s…

Indeed similar to git-annex, why does GitHub not support that? With GitLab we added support for that recently and it was pretty easy to do. Anyway, interesting that linking to sha's is becoming the default solution. Looking forward to playing with this and comparing the solutions.

Re: Announcing Git Large File Storage

#68

Post by sytse »

efuquen wrote: post #57
bhuga wrote: post #31

Earlier quoted context omitted.

> tied to GitHub. The protocol is open ( 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 . edit: added protocol spec

Why 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.

GitLab 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.

Re: Announcing Git Large File Storage

#69

Post by icebraining »

s73v3r wrote: post #62
efuquen wrote: post #56

Earlier quoted context omitted.

I think the question is why did they role their own solution when there was one already an open and freely one available. If it wasn't suitable in some way I would really like to know why.

If git-annex really worked well, and was easy to use, I imagine there'd be much more uptake of it.

"Build it and they will come"

Besides, I'm sure Joey Hess wouldn't refuse the help.

Re: Announcing Git Large File Storage

#70

Post by sjwright »

lebek wrote: post #58
jxf wrote: post #4

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…

Nitpick: they gave four examples of large binary files: audio samples, datasets, graphics, and videos. Diffs would be meaningful in every case.

Surely not diffs offered by the git ecosystem?
Post reply on HN