Re: [RFE] Migration to gitlab

[Basil L. Contovounesios]

조성빈 <address@hidden> writes:

> 2019. 5. 11. 오전 11:12, Alan Mackenzie <address@hidden> 작성:
>
>> I don't know what "pull/merge request" means.  Does it mean a request by
>> an outsider for a core contributor to perform a "git pull" operation
>> from the outsider's computer, the outsider having opened up his machine
>> to public access to allow this?
>
> 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.

FWIW, I *never* use the GitLab/GitHub UI to either (a) edit files, (b)
create commits, or (c) merge merge/pull requests.

Editing files and commit messages in the browser is not only an inferior
experience to doing so in any decent text editor, but is also fraught
with potential issues like accidentally including undesirable
whitespace, omitting a trailing newline, etc.

Merging things with the click of a button means you don't know what's
actually happening, and I always want to control this process to the
greatest extent practical.  Luckily, Git makes this very easy - in my
personal workflow it's as simple as 'git merge --edit --no-ff'
(the --edit allows me to reference the merge request number in the merge
commit message).  Using a Git front-end such as Magit makes this even
easier.  When I then push the changes upstream, GitLab is smart enough
to know that the merge request has been merged and automatically closes
it.

-- 
Basil