<p><strong>When to decide whether a file should go to git LFS</strong></p>

<p>Your files can go to git-lfs at any time, but it would be inneficient to implement this solution for few files. Specially if it's basic gradlew jars.</p>

<p>I have used the gradlew strategy previously. The idea is to push this "wrapper" along your code to make the build process portable. Any platform with the proper JRE will be able to build the application in a similar fashion. This removes the headache of enforcing teams to install specific versions of gradle.</p>

<p>The purpose of gi-lfs is to leverage the benefits of git along with the ability to store large files remotely by caching them and indexing them. It reduces the burden of downloading a big repository when binaries are stored.</p>

<p>In my opinion you should start consider this solution when:</p>

<ul>
<li><p>Your git repository contains large files (anything in the MB magnitude)</p></li>
<li><p>They represent the main content of your repository</p></li>
<li><p>These files are updated regularly</p></li>
<li><p>It is taking your CI tool minutes to pull/clone the repository</p></li>
</ul>

<p>If you consider this solution to track binary versions, I would suggest you go for binary repositories instead such as:</p>

<ul>
<li><a href="https://www.jfrog.com/artifactory/" rel="nofollow noreferrer">Jfrog Artifactory</a></li>
<li><a href="https://archiva.apache.org/index.cgi" rel="nofollow noreferrer">Archiva</a></li>
<li><a href="https://www.sonatype.com/nexus-repository-sonatype" rel="nofollow noreferrer">Nexus</a></li>
</ul>

<p><strong>Does the existing CI configuration will break</strong></p>

<p>If you decide to go git-lfs, the normal git commands won't work. You will need to either create symbolic links toward git-lfs after doing the setup or add <code>lfs</code> after <code>git</code> in your CI tool. i.e. <code>git clone</code> becomes <code>git lfs clone</code>.</p>

CC BY-SA 3.0
2017-12-05T01:52:19.893Z
2017-12-05T01:52:19.893Z
gmolaire
<p>Git large file system git-lfs could be used to store large files and at a txt file to the git repository. The question is when to decide whether a file should go to git LFS and if that is done whether the existing CI configuration will break.</p>

<p>Sometimes jars are added to a repository like the gradlew.jar. According to me, binaries like jars should not be stored in git as these are not text files that change, but a binary does not have to be large.</p>

<p>Currently we have multiple git repositories that contain jar files. I wonder whether all these jars should be moved to git-lfs.</p>

CC BY-SA 3.0
2017-12-03T16:26:05.730Z
What do you want to store?
gmolaire
CC BY-SA 3.0
2017-12-03T16:56:23.690Z
Additional paragraph added.
030
<continuous-integration><git-lfs>
Are there any guidelines for when to use gitlfs and will it break the CI?
030
# Are there any guidelines for when to use gitlfs and will it break the CI?

(Asked by: username_0 on 2017-11-30)

Git large file system git-lfs could be used to store large files and at a txt file to the git repository. The question is when to decide whether a file should go to git LFS and if that is done whether the existing CI configuration will break.

Sometimes jars are added to a repository like the gradlew.jar. According to me, binaries like jars should not be stored in git as these are not text files that change, but a binary does not have to be large.

Currently we have multiple git repositories that contain jar files. I wonder whether all these jars should be moved to git-lfs.

**Tags:** continuous-integration, git-lfs

> **Comments:**
> **username_1**: What do you want to store?  
> **username_0**: Additional paragraph added.  

---

## 1 answers

### Answer by username_1 on 2017-12-05. Score: 4 | Accepted answer

**When to decide whether a file should go to git LFS**

Your files can go to git-lfs at any time, but it would be inneficient to implement this solution for few files. Specially if it's basic gradlew jars.

I have used the gradlew strategy previously. The idea is to push this "wrapper" along your code to make the build process portable. Any platform with the proper JRE will be able to build the application in a similar fashion. This removes the headache of enforcing teams to install specific versions of gradle.

The purpose of gi-lfs is to leverage the benefits of git along with the ability to store large files remotely by caching them and indexing them. It reduces the burden of downloading a big repository when binaries are stored.

In my opinion you should start consider this solution when:

* Your git repository contains large files (anything in the MB magnitude)
* They represent the main content of your repository
* These files are updated regularly
* It is taking your CI tool minutes to pull/clone the repository

If you consider this solution to track binary versions, I would suggest you go for binary repositories instead such as:

* [Jfrog Artifactory](https://www.jfrog.com/artifactory/)
* [Archiva](https://archiva.apache.org/index.cgi)
* [Nexus](https://www.sonatype.com/nexus-repository-sonatype)

**Does the existing CI configuration will break**

If you decide to go git-lfs, the normal git commands won't work. You will need to either create symbolic links toward git-lfs after doing the setup or add `lfs` after `git` in your CI tool. i.e. `git clone` becomes `git lfs clone`.


---

