... | ... | @@ -125,3 +125,28 @@ 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.
|
|
|
|
|
|
## 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.
|
|
|
|
|
|
This limitation for external users has an important result: from the Gitlab point of view, forking a project *is* creating a project, thus external users cannot fork projects.
|
|
|
|
|
|
As a result, the infamous MR (Merge Request) development model cannot be used directly with external users, but some workarounds can be used in some situations.
|
|
|
|
|
|
The MR development model works as follows:
|
|
|
- A restricted core development team is member of a project and has commit access to the development tree
|
|
|
- Some contributor starts contributing by forking the project ("fork" button). When hist contribution is ready, he opens a new merge request (in the "new" menu).
|
|
|
- Someone from the core development team can then accept (or refuse) the Merge Request to be merged in the main development tree
|
|
|
|
|
|
This development model has several benefits:
|
|
|
- It limits the access to the main development tree to a small group of trusted core developers.
|
|
|
- It allows the core development team to control finely which contributions to merge or not.
|
|
|
- In particular, it shields the project and forces all contributions to pass through a validation workflow, such as ensuring that the Continuous Integration passes, or that all intellectual property constraints are satisfied, before merging some development.
|
|
|
- With tools such as Github or Gitlab, the web user interface for merge requests is very user friendly.
|
|
|
|
|
|
So, here are some possible workarounds to this development model when using the Inria Gitlab with external contributors:
|
|
|
- Use pull-requests mechanisms at the git level, rather than at the Gitlab level. This is the way that the Linux kernel has been being developed for a long time now. Instead of submitting a MR with the Gitlab interface, contributors send patches by email.
|
|
|
- For projects with few known external contributors, it is possible that Inria members create forks on behalf of the external contributors, then transfer ownership of these forks to the contributors.
|
|
|
- For projects with few known and trusted external contributors, these contributors can be added to the project but develop in their own branches. But there is no mechanism at Gitlab level to ensure that they don't override their permissions.
|
|
|
|
|
|
If these workarounds do not fit well with what you need and you absolutely want to use the standard MR development model with external contributors, the only solution is to use another tool than the Inria Gitlab. |