... | ... | @@ -2,6 +2,33 @@ |
|
|
|
|
|
# FAQ - Frequently Asked Questions
|
|
|
|
|
|
## Good usage of the gitlab?
|
|
|
|
|
|
Gitlab is initially and mainly aimed at providing a set of tools for collaborative work on software development projects. Additionally, it can also be used for collaborative work on projects not directly related to software development, such as collaborative edition of scientific publications, since source code or text edition are similar.
|
|
|
|
|
|
Keep in mind that the design and sizing of gitlab have some limitations:
|
|
|
|
|
|
* Git is designed to keep a complete history of operations. It is not expected to change this history and doing so is rather convoluted (see related faq entry). This means that if you put a file under git and later remove it, the file will be removed only from the current and following revisions, not from the old ones. Disk space is not reclaimed. If you commit different versions of a single file, each version will be stored and uses disk space.
|
|
|
* Git is best used to store text files (source code, latex source, etc.), because they compress well.
|
|
|
* Git is designed initially to version source code. The size of a git repository such as the linux kernel repository is in the order of 100 to 200 MB (and this is a rather large project). Repositories with sizes wich are one order of magnitude or more greater will be slow.
|
|
|
* The worst case is storing big binary files (they don't compress well)
|
|
|
* Additionally, having huge repositories will impact not only git, but also gitlab as a whole:
|
|
|
* The web interface will be slow (eg. looking at big commits in web interface will timeout)
|
|
|
* Continuous Integration will be impacted (eg. need to have big runners, build artifacts will be huge, and jobs may fail or timeout)
|
|
|
|
|
|
Hence, some gitlab usages are rather inappropriate:
|
|
|
|
|
|
* Using source control to store a lot of binary data (either lots of medium to big files, or a few enormous files).
|
|
|
* In particular, it is bad usage to use the git to publish and share big experimental datasets (inputs or outputs), virtual machine images, and more generally any kind of "big data". You should, instead, version the code for generating this data or vm images.
|
|
|
|
|
|
Alternative solutions:
|
|
|
|
|
|
* If you need to publish huge volumes of data, you need to find some network storage outside of the gitlab. See with your IT contacts for solutions, or find a funding for your own servers / space. The gitlab is not a Dropbox alternative for big data!
|
|
|
* git-lfs may be a good solution but it is not yet activated for the Inria gitlab.
|
|
|
* An alternative to git-lfs is git-annex.
|
|
|
|
|
|
The frontier between good and bad usage of the gitlab is fuzzy, but as there are a lot of users and projects on the gitlab, if too much people abuse the system we will have to put hard limits and restrictions on the gitlab usage, which will be annoying for everyone.
|
|
|
|
|
|
## How to not have to type a password for every git operation
|
|
|
|
|
|
First of all to avoid having to type login/password each type, the best is to use git over ssh rather than git over https (see below for git over http)
|
... | ... | @@ -208,6 +235,8 @@ The git-lfs feature is not activated. To version data or binary files, an option |
|
|
|
|
|
Why isn't git-LFS activated? We observe that many users are trying to use git/gitlab to store huge volumes of data such as experimental datasets, experimental results, binary blobs, big data, etc. Git is not designed to handle such usage, and git-lfs would be the good answer, but because we do not have yet a working, production ready, quota system for gitlab, and because we do not yet have a clear strategy about how to manage such storage, we do not want to encourage such usages, and thus we decided to not enable git-lfs.
|
|
|
|
|
|
You are welcome to tell us if git-lfs is a need for your usage. Your requests will be taken in account for future decisions on this matter.
|
|
|
|
|
|
## Merge Request development model and external contributors
|
|
|
|
|
|
This Inria Gitlab instance offers accounts both to Inria members (who login using their Inria LDAP credentials) and to external users (who can register accounts at this location: https://gitlab-account.inria.fr/). The external (non-inria) users are limited to join existing projects, but cannot create projects on their own.
|
... | ... | |