To me, Git-LFS and Git-Annex when compared to the Mercurial LargeFiles extension, are perfect examples of what's wrong with Git.
Mercurial's LargeFiles extension allows you to do what I would imagine, 90%+ of Git-LFS users will want to do: store some binary assets with their regular source code.
In Mercurial, the files get stored on the shared server, inside the .hg directory of the repo you clone. They are cached between requests client side, and it generally just works. I had to add 2 lines server side, and 5 lines client side (both times in a hgrc file) to enable and test the functionality.
With Git it seems very much that Git-LFS (rather than Git-Annex) is more like what I need to achieve basically the same results/workflow.
Oh wait, but I need a separate Git-LFS server. So, Git-LFS was created by GitHub, and they of course support Git-LFS on their servers.. But I want to manage this repo on my own machines so what can I do..
Oh look GitHib has a reference implementation of a standalone Git-LFS server.. Oh wait. Second sentence of the Readme is a bit ominous:
> It is intended to be used for testing the Git LFS client and is not in a production ready state.
I'm just using regular SSH access to use my Repos, can't I just access the Git-LFS file store that way? Oh. No. I have to expose a HTTP(S) server that accepts basic auth.. Oh and the Git client needs to be able to provide the Authorisation header automatically so I don't get prompted... Oh and the slightest thing can make the "automatic" mapping of URLS from repo to LFS-store not work, meaning I have to specify it manually...
That Git-LFS comes from GitHub and is relatively complex to setup for hosting, is likely not a coincidence. They make money offering 'easy' repo hosting. Why would they want to make it easier to setup your own repo.
> Work like you always do on Git—no need for additional commands, secondary storage systems
So you don't need a secondary storage system... you just need a HTTPS server and Username/Password authentication layer.. but that isn't a secondary system. Just like a Turducken isn't really three birds crammed into one.
1 comment
[ 2.9 ms ] story [ 7.0 ms ] threadMercurial's LargeFiles extension allows you to do what I would imagine, 90%+ of Git-LFS users will want to do: store some binary assets with their regular source code.
In Mercurial, the files get stored on the shared server, inside the .hg directory of the repo you clone. They are cached between requests client side, and it generally just works. I had to add 2 lines server side, and 5 lines client side (both times in a hgrc file) to enable and test the functionality.
With Git it seems very much that Git-LFS (rather than Git-Annex) is more like what I need to achieve basically the same results/workflow.
Oh wait, but I need a separate Git-LFS server. So, Git-LFS was created by GitHub, and they of course support Git-LFS on their servers.. But I want to manage this repo on my own machines so what can I do..
Oh look GitHib has a reference implementation of a standalone Git-LFS server.. Oh wait. Second sentence of the Readme is a bit ominous:
> It is intended to be used for testing the Git LFS client and is not in a production ready state.
I'm just using regular SSH access to use my Repos, can't I just access the Git-LFS file store that way? Oh. No. I have to expose a HTTP(S) server that accepts basic auth.. Oh and the Git client needs to be able to provide the Authorisation header automatically so I don't get prompted... Oh and the slightest thing can make the "automatic" mapping of URLS from repo to LFS-store not work, meaning I have to specify it manually...
That Git-LFS comes from GitHub and is relatively complex to setup for hosting, is likely not a coincidence. They make money offering 'easy' repo hosting. Why would they want to make it easier to setup your own repo.
This line from http://git-lfs.github.com really takes the cake though:
> Work like you always do on Git—no need for additional commands, secondary storage systems
So you don't need a secondary storage system... you just need a HTTPS server and Username/Password authentication layer.. but that isn't a secondary system. Just like a Turducken isn't really three birds crammed into one.