Re: repository at GitLab

[David Kastrup]

Jonas Hahnfeld <address@hidden> writes:

> Am Montag, den 11.05.2020, 14:22 +0200 schrieb David Kastrup:
>> David Kastrup <address@hidden> writes:
>> > Jonas Hahnfeld <address@hidden> writes:
>> > > Am Montag, den 11.05.2020, 12:44 +0200 schrieb David Kastrup:
>> > > > dak@lola:/usr/local/tmp/lilypond$ git push -o merge_request.create
>> > > > -o merge_request.target=staging -o merge_request.title="Issue 5965"
>> > > > origin issue5965:issue5965
>> > > 
>> > > Interesting, didn't know about this possibility...
>> > 
>> > The funny thing is I don't know about any other possibility.  Web
>> > interfaces are not really my thing, and this is what I found when
>> > grasping around.
>
> Just push any new branch to the repository or a fork and you'll be
> presented with a link on the command line. Alternatively GitLab
> remembers your last push and shows a corresponding button somewhere at
> the top.
>
>> > I now try figuring out where my merge request ends up
>> > and how it can be found and treated from the web interface.
>
> It's now here: https://gitlab.com/lilypond/lilypond/-/merge_requests/2
>
>> > It probably should be a project-wide setting to have
>> > merge_request.target=staging as default?
>
> Merge requests are opened against the default branch, which is set to
> 'master' right now. I can of course switch to 'staging', but that would
> also mean a fresh clone starts at 'staging' which is probably not what
> we want.
>
>> > > Just added you (and all others that were in lilypond-trial) to the
>> > > lilypond group.
>> > 
>> > Thanks.
>> 
>> And actually, I don't know what the workflow right now is and whether I
>> even was supposed to push something to the central repo to get it (back)
>> under review.  This was basically just me prodding the repo for lack of
>> any other idea of how to interact.  I know now how to do one thing.  I
>> just don't know whether this is what I am supposed to be doing.
>
> Yes, I think pushing existing reviews as a merge request is the easiest
> solution. For the beginning we could of course also live with a mixture
> of (old-style) issues and merge requests, but the countdown script I
> wrote for James only considers merge requests. So pushing as a branch
> and adding the previous label to the MR would be great.
>
> For merging I would not use the UI yet but manually push to staging as
> before. So targeting 'master' by default for now shouldn't be a
> problem.

It turns out that issues have above the discussion a menu entry to open
a merge request.  I have not found an obvious way to link a merge
request created independently to an issue.

So instead of pushing independently as a merge request (unless the merge
request is of the common form of stating and solving a problem or task
at the same time), it seems to be the right way to open the merge
request in the existing issue and go from there.

I'll try doing that in parallel now, and possibly decide to kill the
independent merge request if that works.

-- 
David Kastrup