... | ... | @@ -38,6 +38,11 @@ Checkout all relevant branches of the git repository, add the gitlab project as |
|
|
|
|
|
If needed, you can filter out part of the history before pushing it to the new gitlab git repository, with tools such as [git-filter-repo](https://github.com/newren/git-filter-repo), [bfg-ish](https://github.com/newren/git-filter-repo/blob/master/contrib/filter-repo-demos/bfg-ish), [BFG Repo Cleaner](https://rtyley.github.io/bfg-repo-cleaner/).
|
|
|
|
|
|
#### Mapping subversion / git committer to gitlab users
|
|
|
|
|
|
Git itself has no knowledge of forge / gitlab users. From git point of view, the author of a commit is a string
|
|
|
Gitlab maps commit authors to gitlab users accounts with the [git .mailmap file](https://git-scm.com/docs/git-check-mailmap). It allows solving situations where a forge svn or git repository is migrated to gitlab and some users don't have the same username between the forge and the gitlab. It also allows solving situations where some users have committed with varying names/addresses during the life of the project.
|
|
|
|
|
|
## Subversion / Git Hooks
|
|
|
|
|
|
Classic subversion or git hooks, implemented as executable in the hooks directories of the subversion or git server repositories, are not possible on the gitlab. So the usual email on subversion commit / git push has no direct equivalent. Gitlab has the concept of notifications, where this is the user who decides what he/she wants to be notified for. But git push are not part of the notified events. So the best equivalent of the email on commit/push is to activate "Emails on push" in the gitlab project integrations.
|
... | ... | |