[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFE] Migration to gitlab

From: Basil L. Contovounesios
Subject: Re: [RFE] Migration to gitlab
Date: Sat, 11 May 2019 20:25:00 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> From: 조성빈 <address@hidden>
>> Date: Sat, 11 May 2019 12:47:27 +0900
>> Cc: Alex Gramiak <address@hidden>, Eli Zaretskii <address@hidden>,
>>  address@hidden, address@hidden, address@hidden,
>>  address@hidden
>> 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).
> Does "clicking a button" take care of various minor details I
> frequently need to do when applying patches from random contributors,
> such as fixing the log messages (or providing them in the first
> place), adding a reference to the bug/issue, adding the
> Copyright-paperwork-exempt tag, etc.?

No, but as I mentioned in my other message, you needn't use the button,
and can cause merge requests to be closed by pushing the relevant
changes to the target branch; GitLab then knows that the merge request
was merged.

I think the way it knows this is by checking that the commits comprising
the merge request are contained in the target branch.  This means that
any edits made to the commits outside of the merge request may confuse
GitLab, as the commit hashes will have changed (as Dmitry mentions

In this case I think you need to either close the merge request manually
by clicking a button, or include an automatically stripped "quick
action" command such as "/close" in a comment to the merge request, or
make sure one of the merge request's commits include a similar command
such as "closes #123".

>> 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.)
> We currently have the opposite situation: pushing a fix doesn't
> automatically close the issue.  Both are bad as defaults, because IME
> what needs to be done is split roughly 50%.  So a much better UI would
> be to force the user to check a box when "clicking the merge button".

Given my description above, I think (in the case of GitLab) this would
be similar to the current requirement of including the bug number in log
messages, though its purpose would also be administrative, not just for



reply via email to

[Prev in Thread] Current Thread [Next in Thread]