3 ms·

My team doesn't write long format commit messages and it's never been an issue. When we need to track down changes we use the corresponding mr, which includes a

by kace91 6y ago

My team doesn't write long format commit messages and it's never been an issue. When we need to track down changes we use the corresponding mr, which includes a description as well as a link to the relevant cards. I personally like this format more because it lets you both be "dirty" in your branch writing commits for yourself, and not have to use amends/rebasing. I can see how it would be annoying for someone that does all the digging on the terminal through git log and blame, but we all use gitlab instead.

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 ago
  Hi, 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 ago
  Unrelated question but why don't more people use Gerrit instead of Gitlab or Github? To me Gerrit flow makes the most sense.
  - brandmeyer 6y ago
    Speaking 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.

by kace91 6y ago

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 ago
Hi, 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 ago
Unrelated question but why don't more people use Gerrit instead of Gitlab or Github? To me Gerrit flow makes the most sense.
- brandmeyer 6y ago
  Speaking 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.