5 ms·

Great to see MS working on this, and also posting the code! "As a side effect, this approach also has some very nice characteristics for large binary files. It

Great to see MS working on this, and also posting the code! "As a side effect, this approach also has some very nice characteristics for large binary files. It doesn’t extend Git with a new mechanism like LFS does, no turds, etc. It allows you to treat large binary files like any other file but it only downloads the blobs you actually ever touch." It seems every day I see another attempt to scale Git to support storage of large files. IMHO lack of large file support is the Achilles Heel of git. So far I am somewhat happy with Git LFS despite some pretty serious limitations - mainly the damage a user who doesn't have Git LFS installed can inflict when they push a binary file to a repo. I'm curious what other folks on HN use to store large files in Git without allowing duplication?

herbst 10y ago
I yet have to run into a issue where i even want a large file in git.
- bluejekyll 10y ago
  The common case that I see are binaries that are being versioned through the VCS. Large binaries, be they libraries or the application, are stored in the VCS and it is used as the source of truth from that point on. Git explicitly called this out as a bad practice. Other vendors, like Perforce, never really did an amazing job with it, but it worked and on top of that, created more reliance on the vendor's system. Now that most people see the shear productivity gains of Git over centralized VCS systems, everyone wants to move, but that comes with a catch. Many of these companies have large workflows built around the way that their old VCS works, and even have compliance rules that have that methodology written into things like their SOX compliance regulations. It's this set of people, that generally have this issue. For everyone else, using just boring old disks is fine for packages and built product as that can be recreated from the SCM. Now, with LFS in Git, you can maintain the same workflow as you had in your old VCS, without changing the entire structure of the organization to work with it.
  - luckydude 10y ago
    BitKeeper did stuff like LFS except you can have more than one binary server: http://www.mcvoy.com/lm/bkdocs/HOWTO-BAM.html http://www.mcvoy.com/lm/bkdocs/HOWTO-BAM.html

herbst 10y ago

I yet have to run into a issue where i even want a large file in git.

bluejekyll 10y ago
The common case that I see are binaries that are being versioned through the VCS. Large binaries, be they libraries or the application, are stored in the VCS and it is used as the source of truth from that point on. Git explicitly called this out as a bad practice. Other vendors, like Perforce, never really did an amazing job with it, but it worked and on top of that, created more reliance on the vendor's system. Now that most people see the shear productivity gains of Git over centralized VCS systems, everyone wants to move, but that comes with a catch. Many of these companies have large workflows built around the way that their old VCS works, and even have compliance rules that have that methodology written into things like their SOX compliance regulations. It's this set of people, that generally have this issue. For everyone else, using just boring old disks is fine for packages and built product as that can be recreated from the SCM. Now, with LFS in Git, you can maintain the same workflow as you had in your old VCS, without changing the entire structure of the organization to work with it.
- luckydude 10y ago
  BitKeeper did stuff like LFS except you can have more than one binary server: http://www.mcvoy.com/lm/bkdocs/HOWTO-BAM.html http://www.mcvoy.com/lm/bkdocs/HOWTO-BAM.html