Staring in 2017 Week 50, Git LFS support is no longer a prototype and is instead gated by the `diffusion.allow-git-lfs` option. Enabling this option will allow Git LFS to use Phabricator as a filestore.
If you want to allow Git LFS in only some repositories, you can use a Herald rule like the one described in T8644#233752 to selectively enable LFS based on repositories, users, etc. Note that once a repository has even one LFS file in it, it may require a lot of work to turn back the clock and move away from LFS, so it is reasonable to be cautious about deploying LFS.
{T7789} discusses the implementation in more detail. Known issues include:
- LFS data is not currently pushed to staging areas. This is a limitation in LFS (`git push <origin-url> <hash>:<ref>` does not push LFS data) which we may try to address in the upstream (see [[ https://github.com/git-lfs/git-lfs/issues/1100 | Git LFS #1100 ]] as a starting point) or may try to work around in a future version of `arc`.
- Drydock working copy operations are yet not LFS aware (see T11195).
- Administrative and operational tools are currently fairly limited and rough.
- We are not supporting LFS in the Phacility cluster at this time (internal change D18826 documents this explicitly). This is mostly an interest/operational issue rather than a technical one. If you're a customer and you're interested in LFS support, let us know through your instance Support channel.
Usually, we ship features only after they appear stable in development (or internal production) environments for some time. We do not use LFS internally and have no plans to ever use it, so LFS is less vetted than other features. Although LFS generally seems to work for installs that have deployed it during the prototype phase, we've also seen a larger-than-usual number of reports of phantom issues which are resistant to reproduction. Outside of the above we aren't aware of any reproducible bugs with the implementation today, but it is reasonable to be cautious about deploying LFS.