You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+23-19Lines changed: 23 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -86,7 +86,7 @@ Leave it null for the first run of the script. Then the script will show you whi
86
86
87
87
#### gitlab.listArchivedProjects
88
88
89
-
When listing projects on the first run (projectID = null), include archived ones too. The default is *true*.
89
+
When listing projects on the first run (projectID = null), include archived ones too. The default is `true`.
90
90
91
91
#### gitlab.sessionCookie
92
92
@@ -108,25 +108,25 @@ Under which organisation or user will the new project be hosted
108
108
109
109
#### github.ownerIsOrg
110
110
111
-
A boolean indicator (default is *false*) to specify that the owner of this repo is an Organisation.
111
+
A boolean indicator (default is `false`) to specify that the owner of this repo is an Organisation.
112
112
113
113
#### github.token
114
114
115
115
Go to [Settings / Developer settings / Personal access tokens](https://github.com/settings/tokens). Generate a new token with `repo` scope and copy that into the `settings.ts`
116
116
117
117
#### github.token_owner
118
118
119
-
Set to the user name of the user whose token is used (see above). This is required to determine whether the user running the migration is also the creator of comments and issues. If this is the case and `useIssueCreationAPI` is true (see below), the extra line specifying who created a comment or issue will not be added.
119
+
Set to the user name of the user whose token is used (see above). This is required to determine whether the user running the migration is also the creator of comments and issues. If this is the case and `useIssueCreationAPI` is `true` (see below), the extra line specifying who created a comment or issue will not be added.
120
120
121
121
#### github.repo
122
122
123
123
What is the name of the new repo
124
124
125
125
#### github.recreateRepo
126
126
127
-
If true (default is false), we will try to delete the destination github repository if present, and (re)create it. The github token must be granted `delete_repo` scope. The newly created repository will be made private by default.
127
+
If `true` (default is `false`), we will try to delete the destination github repository if present, and (re)create it. The github token must be granted `delete_repo` scope. The newly created repository will be made private by default.
128
128
129
-
If you've set `github.recreateRepo` to true and the repo belongs to an Organisation, the `github.ownerIsOrg` flag **must** be set as true.
129
+
If you've set `github.recreateRepo` to `true` and the repo belongs to an Organisation, the `github.ownerIsOrg` flag **must** be set as `true`.
130
130
131
131
This is useful when debugging this tool or a specific migration. You will always be prompted for confirmation.
132
132
@@ -160,63 +160,67 @@ When one renames the project while transfering so that the projects don't loose
160
160
161
161
#### conversion.useLowerCaseLabels
162
162
163
-
If this is set to true (default) then labels from GitLab will be converted to lowercase in GitHub.
163
+
If this is set to `true` (default) then labels from GitLab will be converted to lowercase in GitHub.
164
+
165
+
#### conversion.addIssueInformation
166
+
167
+
If this is set to `true` (default) then issues and pull requests will get information about assignees (both), reviewers and approvers (PR only) added to their description.
164
168
165
169
### transfer
166
170
167
171
#### transfer.milestones
168
172
169
-
If this is set to true (default) then the migration process will transfer milestones.
173
+
If this is set to `true` (default) then the migration process will transfer milestones.
170
174
171
175
#### transfer.labels
172
176
173
-
If this is set to true (default) then the migration process will transfer labels.
177
+
If this is set to `true` (default) then the migration process will transfer labels.
174
178
175
179
#### transfer.issues
176
180
177
-
If this is set to true (default) then the migration process will transfer issues.
181
+
If this is set to `true` (default) then the migration process will transfer issues.
178
182
179
183
#### transfer.mergeRequests
180
184
181
-
If this is set to true (default) then the migration process will transfer merge requests.
185
+
If this is set to `true` (default) then the migration process will transfer merge requests.
182
186
183
187
#### transfer.releases
184
188
185
-
If this is set to true (default) then the migration process will transfer releases.
189
+
If this is set to `true` (default) then the migration process will transfer releases.
186
190
Note that github api for releases is limited and hence this will only transfer the title and description of the releases
187
191
and add them to github in chronological order, but it would not preserve the original release dates, nor transfer artefacts or assets.
188
192
189
193
### dryRun
190
194
191
-
As default it is set to false. Doesn't fire the requests to github api and only does the work on the gitlab side to test for wonky cases before using up api-calls
195
+
As default it is set to `false`. Doesn't fire the requests to github api and only does the work on the gitlab side to test for wonky cases before using up api-calls
192
196
193
197
### exportUsers
194
198
195
-
If this is set to true (default is false) then a file called "users.txt" wil be created containing all
199
+
If this is set to `true` (default is `false`) then a file called "users.txt" wil be created containing all
196
200
usernames that contributed to the repository. You can use this with dryRun when you need to map users
197
201
for the migration, but you do not know all the source usernames.
198
202
199
203
### useIssueImportAPI
200
204
201
-
Set to true (default) to enable using the [GitHub preview API for importing issues](https://gist.github.com/jonmagic/5282384165e0f86ef105). This allows setting the date for issues and comments instead of inserting an additional line in the body.
205
+
Set to `true` (default) to enable using the [GitHub preview API for importing issues](https://gist.github.com/jonmagic/5282384165e0f86ef105). This allows setting the date for issues and comments instead of inserting an additional line in the body.
202
206
203
207
### usePlaceholderIssuesForMissingIssues
204
208
205
-
If this is set to true (default) then the migration process will automatically create empty dummy issues for every 'missing' GitLab issue (if you deleted a GitLab issue for example). Those issues will be closed on Github and they ensure that the issue ids stay the same on both GitLab and Github.
209
+
If this is set to `true` (default) then the migration process will automatically create empty dummy issues for every 'missing' GitLab issue (if you deleted a GitLab issue for example). Those issues will be closed on Github and they ensure that the issue ids stay the same on both GitLab and Github.
206
210
207
211
#### usePlaceholderMilestonesForMissingMilestones
208
212
209
-
If this is set to true (default) then the migration process will automatically create empty dummy milestones for every 'missing' GitLab milestone (if you deleted a GitLab milestone for example). Those milestones will be closed on Github and they ensure that the milestone ids stay the same on both GitLab and Github.
213
+
If this is set to `true` (default) then the migration process will automatically create empty dummy milestones for every 'missing' GitLab milestone (if you deleted a GitLab milestone for example). Those milestones will be closed on Github and they ensure that the milestone ids stay the same on both GitLab and Github.
210
214
211
215
#### useReplacementIssuesForCreationFails
212
216
213
-
If this is set to true (default) then the migration process will automatically create so called "replacement-issues" for every issue where the migration fails. This replacement issue will be exactly the same, but the original description will be lost. In the future, the description of the replacement issue will also contain a link to the original issue on GitLab. This way, users who still have access to the GitLab repository can still view its content. However, this is still an open task. (TODO)
217
+
If this is set to `true` (default) then the migration process will automatically create so called "replacement-issues" for every issue where the migration fails. This replacement issue will be exactly the same, but the original description will be lost. In the future, the description of the replacement issue will also contain a link to the original issue on GitLab. This way, users who still have access to the GitLab repository can still view its content. However, this is still an open task. (TODO)
214
218
215
219
It would of course be better to find the cause for migration fails, so that no replacement issues would be needed. Finding the cause together with a retry-mechanism would be optimal, and will maybe come in the future - currently the replacement-issue-mechanism helps to keep things in order.
216
220
217
221
### useIssuesForAllMergeRequests
218
222
219
-
If this is set to true (default is false) then all merge requests will be migrated as GitHub issues (rather than pull requests). This can be
223
+
If this is set to `true` (default is `false`) then all merge requests will be migrated as GitHub issues (rather than pull requests). This can be
220
224
used to sidestep the problem where pull requests are rejected by GitHub if the feature branch no longer exists or has been merged.
221
225
222
226
### filterByLabel
@@ -238,7 +242,7 @@ Suggested values:
238
242
239
243
### mergeRequests
240
244
241
-
Object consisting of `logfile` and `log`. If `log` is set to true, then the merge requests are logged in the specified file and not migrated. Conversely, if `log` is set to false, then the merge requests are migrated to GitHub and not logged. If the source or target branches linked to the merge request have been deleted, the merge request cannot be migrated to a pull request; instead, an issue with a custom "gitlab merge request" tag is created with the full comment history of the merge request.
245
+
Object consisting of `logfile` and `log`. If `log` is set to `true`, then the merge requests are logged in the specified file and not migrated. Conversely, if `log` is set to `false`, then the merge requests are migrated to GitHub and not logged. If the source or target branches linked to the merge request have been deleted, the merge request cannot be migrated to a pull request; instead, an issue with a custom "gitlab merge request" tag is created with the full comment history of the merge request.
0 commit comments