Hacker News Reader

Comment by Doji | Hacker News Reader

So basically it's git-annex, but tied to GitHub. http://git-annex.branchable.com/

> 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

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

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.

You'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!

Embrace. Extend. Extinguish.

All GitLab contributors are working on an alternative ending.

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.

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

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

To 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

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.

(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?

> (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 normal project workflow than GitHub's lfs.

[1]http://git-annex.branchable.com/git-annex/

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.

If you want to use git-annex without any setup consider using GitLab.com, it is enabled by default and free to use.

Make a Kickstarter to put it in Gitlab CE, I'd propose.

We'd be up for that :)

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?

Yes, you can. That's one other advantage over git-annex (albeit slight).

The documentation lays out the workflow: https://help.github.com/articles/configuring-large-file-stor...

As does the website: https://git-lfs.github.com/ (see: "Getting Started")

Righto. So what is the equivalent thing with git-annex? Would I have to essentially do two commits, one for source code and one for large objects?

I'm still ramping up on git-annex, but basically (once set up):

    git annex add large_file
    git commit

And with mixed (haven't experimented with that yet), I'm pretty sure you could: git annex add large_file git add small_file git commit

Yes, you can mix them just fine.

Yeah, that was exactly my feeling.

"Not invented here" much?

they are trying to make a service. If you are making a product you generally want to be in control of its core parts.

If you use another open source project that gives you control right? It would be nice if everyone reused git-annex like they reused git.

Reply on news.ycombinator.com