|Subject:||Re: [RFE] Migration to gitlab|
|Date:||Sat, 11 May 2019 12:47:27 +0900|
2019. 5. 11. 오전 11:12, Alan Mackenzie <address@hidden> 작성:
An outsider that is not a core contributor cannot make a new branch (as he/she doesn’t have enough authorization).
So the outsider can ‘fork’ the repo, to make an exact clone of it, push his/her changes(commits) to GitLab, and make a merge request. The pull/merge request is a request the core contributor to ‘pull’ the changes of the forked repo and ‘merge’ it just as if the forked repo is just another branch.
This can be done by just clicking a button to merge(in the web UI).
Merging is also available in the command line; see https://gist.github.com/adam-p/15413fabef6cffecd897 ; but I’ve never seen anyone merging PRs like that in real life.
IIRC Gitlab uses one number for all ‘topic’s, but there are two types of topics(e.g. issue and PR). If you were annoyed that there are few types of different numbers, (e.g. Bug#71 and Analysis#71), GitLab is not the case.
There is only one #71 and it’s an issue or PR.
When the core contributor decides that the PR is done and merges it to the main repo, GitLab automatically closes the issue. (If the PR was found to be an incomplete solution, the issue can be re-opened.)
As I mentioned before, they don’t have ‘distinct’ identifiers; any issue/PR can cross-reference other issue/PR with the number.
If you’re saying what’s the point of having two types of topics(issues and PRs), it’s that PRs are primarily a way to put code, while issues are primarily a way to report bugs, feature requests.
If an core contributor fixed an issue, one doesn’t have to create a PR(as he/she already has commit; he/she can just mention the issue number in the commit message and it will be automatically closed.
No, one can interact with the bug while writing a patch and making a PR (or a commit). You can make a PR and continue to modify the PR (as the bug gets resolved?) until it becomes merged.
|[Prev in Thread]||Current Thread||[Next in Thread]|