4 ms·
If you ever switch from Gitlab to another git host, you’ll lose all that history though. Maybe you’re fine with that, but I wouldn’t be.
by ryukafalz 6y ago
If you ever switch from Gitlab to another git host, you’ll lose all that history though. Maybe you’re fine with that, but I wouldn’t be.
- dnsmichi 6y agoHi, Developer Evangelist at GitLab here. While we do not want you to leave ... :-) ... you'll have great tools to export your data from projects, for example https://docs.gitlab.com/ee/user/project/settings/import_export.html https://docs.gitlab.com/ee/user/project/settings/import_expo... Another way is to programmatically work with the REST API and export the needed data (https://docs.gitlab.com/ee/api/ https://docs.gitlab.com/ee/api/). This can be needed to specific backup and persistence routines for data compliance too. I personally recommend to use the Python, Ruby, etc. library bindings for easier API requests. This won't solve the import into another tool, yet it opens a migration possibility with full access via an API.
- pdsOne 6y agoUnrelated question but why don't more people use Gerrit instead of Gitlab or Github? To me Gerrit flow makes the most sense.
- brandmeyer 6y agoSpeaking only for myself: Because Gerrit's unit of review is a single commit instead of a branch. Commits are units of change, but the unit of work and review is almost always a series of related changes. Just because the changes are individually atomic (testable, cherry-pickable, etc) doesn't mean that I want to review them that way. The typical flow is for an engineer to produce a cluster of inter-related changes that motivate and rationalize each other. Reviewing such a chunk in Gerrit is a PITA. It breaks up the flow of discussion and encourages a myopic perspective on the work.