[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: repository at GitLab
From: |
Jonas Hahnfeld |
Subject: |
Re: repository at GitLab |
Date: |
Mon, 11 May 2020 14:31:20 +0200 |
User-agent: |
Evolution 3.36.2 |
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
- Re: repository at GitLab, (continued)
- Re: repository at GitLab, David Kastrup, 2020/05/11
- Re: repository at GitLab, Jonas Hahnfeld, 2020/05/11
- Re: repository at GitLab, David Kastrup, 2020/05/11
- Re: repository at GitLab, David Kastrup, 2020/05/11
- Re: repository at GitLab, Jonas Hahnfeld, 2020/05/11
- Re: repository at GitLab, David Kastrup, 2020/05/11
- Re: repository at GitLab, David Kastrup, 2020/05/11
- Re: repository at GitLab,
Jonas Hahnfeld <=
- Re: repository at GitLab, David Kastrup, 2020/05/11
- Re: repository at GitLab, Jonas Hahnfeld, 2020/05/11
- Re: repository at GitLab, David Kastrup, 2020/05/11
- Re: repository at GitLab, Jonas Hahnfeld, 2020/05/11
Re: repository at GitLab, Thomas Morley, 2020/05/12