# 2018.10.30 Hangout

**URL:** <https://discourse.slicer.org/t/2018-10-30-hangout/4588>\
**Category:** Weekly meetings\
**Created:** [October 30, 2018, 10:39am UTC](https://discourse.slicer.org/t/2018-10-30-hangout/4588 "2018-10-30T10:39:36Z")\
**Posts on this page:** 1\
**Showing post:** 5

<div class="post-metadata">

**Author:** ![lassoan](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.slicer.org/lassoan/32/13_2.png) [@lassoan](https://discourse.slicer.org/u/lassoan)\
**Post date:** [November 2, 2018, 4:29pm UTC](https://discourse.slicer.org/t/2018-10-30-hangout/4588/5 "2018-11-02T16:29:32Z")

</div>

Regarding using git-lfs for documentation:

I’ve done some tests - see details here: [Should we use Git LFS to manage data?](https://discourse.slicer.org/t/should-we-use-git-lfs-to-manage-data/2448/13?u=lassoan)

In summary: git-lfs is not fully supported by GitHub web interface (for example, cannot upload git-lfs file trough web interface) and still not very robust (may break due to user errors, symlinks, merges, changing of git attributes, etc.).

**Short term:** I think we should not start using git-lfs now. Instead, we can store large documentation files (mainly screenshot files) as regular files. If we keep image sizes small then the repository size will remain manageable.

**Long term:** If we find that repository has become too large (not very likely to happen within a couple of years) then we can decide to move existing files to git-lfs or other solution that will be a state-of-the-art then. There is already a git-lfs command that can convert existing files to git-lfs files, so we could easily migrate any time we decide to do so.

---

_[View the full topic](https://discourse.slicer.org/t/2018-10-30-hangout/4588)._
