Re: repository at GitLab

[Jonas Hahnfeld]

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.

Jonas

signature.asc
Description: This is a digitally signed message part