Re: repository at GitLab
Am Di., 12. Mai 2020 um 09:19 Uhr schrieb Thomas Morley : > > Am Di., 12. Mai 2020 um 08:47 Uhr schrieb Jonas Hahnfeld : > > > > Am Dienstag, den 12.05.2020, 08:43 +0200 schrieb Thomas Morley: > > > Am Di., 12. Mai 2020 um 08:32 Uhr schrieb Jonas Hahnfeld > > > : > > > > Am Dienstag, den 12.05.2020, 08:24 +0200 schrieb Thomas Morley: > > > > > Hi, > > > > > > > > > > currently I've very little time to work on LilyPond or to monitor the > > > > > mailing-lists at all, thus I apologize if this is already answered > > > > > elsewhere. > > > > > For now I'll expect me getting familiar with GitLab very slowly... > > > > > > > > > > Nevertheless, I just did: > > > > > $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git > > > > > > > > > > Next I wanted to do: > > > > > $ git fetch > > > > > returning: > > > > > The authenticity of host 'gitlab.com > > > > > (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. > > > > > ECDSA key fingerprint is > > > > > SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. > > > > > Are you sure you want to continue connecting (yes/no)? > > > > > > > > > > What to do? > > > > > > > > It prompts you to confirm that it's really gitlab.com that you're > > > > connecting to. As SSH uses no certificates, that's on the user to do. > > > > The usual way is to verify the fingerprint, which are published here: > > > > https://docs.gitlab.com/ee/user/gitlab_com/index.html#ssh-host-keys-fingerprints > > > > > > > > As they match, you probably want to continue (unless you consider the > > > > possibility that somebody hijacked both the website for both of us and > > > > the SSH connection to a spoofed host...) > > > > > > > > Jonas > > > > > > I now get: > > > $ git fetch > > > The authenticity of host 'gitlab.com > > > (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. > > > ECDSA key fingerprint is > > > SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. > > > Are you sure you want to continue connecting (yes/no)? yes > > > Warning: Permanently added > > > 'gitlab.com,2606:4700:90:0:f22e:fbec:5bed:a9b9' (ECDSA) to the list of > > > known hosts. > > > Connection closed by 2606:4700:90:0:f22e:fbec:5bed:a9b9 port 22 > > > fatal: Could not read from remote repository. > > > > > > Please make sure you have the correct access rights > > > and the repository exists. > > > > Did you add the SSH key to your GitLab account? If not, see this > > documentation page: > > https://docs.gitlab.com/ee/ssh/README.html#adding-an-ssh-key-to-your-gitlab-account > > > > Regards > > Jonas > > Well, as far as I can tell, I did as you adviced. > Though: > $ git fetch > now wants a password, though I never set one for this repo. > > I give up for now, probably I wait for the updated CG, please make > sure it's written for very dumb dummies... > > Many thans for your advice, best > Harm I think I've found the culprit. Previously I had a couple of lilypond-git-repos (mainly because I could switch between compilations with different guile-versions very conveniant), but only one, protected by a password, for doing serious work, patches, push etc. The others were not set up for push. Looks like the repo I took for testing access to GitLab is now the main, password-protected repo. Which is ok for me. Seems it's time for some clean up with my repos ... well ... if I find the time ... Many thanks again. Harm
Re: repository at GitLab
Am Di., 12. Mai 2020 um 08:47 Uhr schrieb Jonas Hahnfeld : > > Am Dienstag, den 12.05.2020, 08:43 +0200 schrieb Thomas Morley: > > Am Di., 12. Mai 2020 um 08:32 Uhr schrieb Jonas Hahnfeld : > > > Am Dienstag, den 12.05.2020, 08:24 +0200 schrieb Thomas Morley: > > > > Hi, > > > > > > > > currently I've very little time to work on LilyPond or to monitor the > > > > mailing-lists at all, thus I apologize if this is already answered > > > > elsewhere. > > > > For now I'll expect me getting familiar with GitLab very slowly... > > > > > > > > Nevertheless, I just did: > > > > $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git > > > > > > > > Next I wanted to do: > > > > $ git fetch > > > > returning: > > > > The authenticity of host 'gitlab.com > > > > (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. > > > > ECDSA key fingerprint is > > > > SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. > > > > Are you sure you want to continue connecting (yes/no)? > > > > > > > > What to do? > > > > > > It prompts you to confirm that it's really gitlab.com that you're > > > connecting to. As SSH uses no certificates, that's on the user to do. > > > The usual way is to verify the fingerprint, which are published here: > > > https://docs.gitlab.com/ee/user/gitlab_com/index.html#ssh-host-keys-fingerprints > > > > > > As they match, you probably want to continue (unless you consider the > > > possibility that somebody hijacked both the website for both of us and > > > the SSH connection to a spoofed host...) > > > > > > Jonas > > > > I now get: > > $ git fetch > > The authenticity of host 'gitlab.com > > (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. > > ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. > > Are you sure you want to continue connecting (yes/no)? yes > > Warning: Permanently added > > 'gitlab.com,2606:4700:90:0:f22e:fbec:5bed:a9b9' (ECDSA) to the list of > > known hosts. > > Connection closed by 2606:4700:90:0:f22e:fbec:5bed:a9b9 port 22 > > fatal: Could not read from remote repository. > > > > Please make sure you have the correct access rights > > and the repository exists. > > Did you add the SSH key to your GitLab account? If not, see this > documentation page: > https://docs.gitlab.com/ee/ssh/README.html#adding-an-ssh-key-to-your-gitlab-account > > Regards > Jonas Well, as far as I can tell, I did as you adviced. Though: $ git fetch now wants a password, though I never set one for this repo. I give up for now, probably I wait for the updated CG, please make sure it's written for very dumb dummies... Many thans for your advice, best Harm
Re: repository at GitLab
Am Dienstag, den 12.05.2020, 08:43 +0200 schrieb Thomas Morley: > Am Di., 12. Mai 2020 um 08:32 Uhr schrieb Jonas Hahnfeld : > > Am Dienstag, den 12.05.2020, 08:24 +0200 schrieb Thomas Morley: > > > Hi, > > > > > > currently I've very little time to work on LilyPond or to monitor the > > > mailing-lists at all, thus I apologize if this is already answered > > > elsewhere. > > > For now I'll expect me getting familiar with GitLab very slowly... > > > > > > Nevertheless, I just did: > > > $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git > > > > > > Next I wanted to do: > > > $ git fetch > > > returning: > > > The authenticity of host 'gitlab.com > > > (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. > > > ECDSA key fingerprint is > > > SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. > > > Are you sure you want to continue connecting (yes/no)? > > > > > > What to do? > > > > It prompts you to confirm that it's really gitlab.com that you're > > connecting to. As SSH uses no certificates, that's on the user to do. > > The usual way is to verify the fingerprint, which are published here: > > https://docs.gitlab.com/ee/user/gitlab_com/index.html#ssh-host-keys-fingerprints > > > > As they match, you probably want to continue (unless you consider the > > possibility that somebody hijacked both the website for both of us and > > the SSH connection to a spoofed host...) > > > > Jonas > > I now get: > $ git fetch > The authenticity of host 'gitlab.com > (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. > ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. > Are you sure you want to continue connecting (yes/no)? yes > Warning: Permanently added > 'gitlab.com,2606:4700:90:0:f22e:fbec:5bed:a9b9' (ECDSA) to the list of > known hosts. > Connection closed by 2606:4700:90:0:f22e:fbec:5bed:a9b9 port 22 > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. Did you add the SSH key to your GitLab account? If not, see this documentation page: https://docs.gitlab.com/ee/ssh/README.html#adding-an-ssh-key-to-your-gitlab-account Regards Jonas signature.asc Description: This is a digitally signed message part
Re: repository at GitLab
Am Di., 12. Mai 2020 um 08:32 Uhr schrieb Jonas Hahnfeld : > > Am Dienstag, den 12.05.2020, 08:24 +0200 schrieb Thomas Morley: > > Hi, > > > > currently I've very little time to work on LilyPond or to monitor the > > mailing-lists at all, thus I apologize if this is already answered > > elsewhere. > > For now I'll expect me getting familiar with GitLab very slowly... > > > > Nevertheless, I just did: > > $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git > > > > Next I wanted to do: > > $ git fetch > > returning: > > The authenticity of host 'gitlab.com > > (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. > > ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. > > Are you sure you want to continue connecting (yes/no)? > > > > What to do? > > It prompts you to confirm that it's really gitlab.com that you're > connecting to. As SSH uses no certificates, that's on the user to do. > The usual way is to verify the fingerprint, which are published here: > https://docs.gitlab.com/ee/user/gitlab_com/index.html#ssh-host-keys-fingerprints > As they match, you probably want to continue (unless you consider the > possibility that somebody hijacked both the website for both of us and > the SSH connection to a spoofed host...) > > Jonas I now get: $ git fetch The authenticity of host 'gitlab.com (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'gitlab.com,2606:4700:90:0:f22e:fbec:5bed:a9b9' (ECDSA) to the list of known hosts. Connection closed by 2606:4700:90:0:f22e:fbec:5bed:a9b9 port 22 fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. I guess I need some GitLab-for-dummies-guide... Cheers, Harm
Re: repository at GitLab
Am Dienstag, den 12.05.2020, 08:24 +0200 schrieb Thomas Morley: > Hi, > > currently I've very little time to work on LilyPond or to monitor the > mailing-lists at all, thus I apologize if this is already answered > elsewhere. > For now I'll expect me getting familiar with GitLab very slowly... > > Nevertheless, I just did: > $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git > > Next I wanted to do: > $ git fetch > returning: > The authenticity of host 'gitlab.com > (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. > ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. > Are you sure you want to continue connecting (yes/no)? > > What to do? It prompts you to confirm that it's really gitlab.com that you're connecting to. As SSH uses no certificates, that's on the user to do. The usual way is to verify the fingerprint, which are published here: https://docs.gitlab.com/ee/user/gitlab_com/index.html#ssh-host-keys-fingerprints As they match, you probably want to continue (unless you consider the possibility that somebody hijacked both the website for both of us and the SSH connection to a spoofed host...) Jonas signature.asc Description: This is a digitally signed message part
Re: repository at GitLab
Am Mo., 11. Mai 2020 um 09:14 Uhr schrieb Jonas Hahnfeld : > > Everything went pretty much as expected, so here's the repo: > https://gitlab.com/lilypond/lilypond > If you already have a local repository cloned from Savannah, execute > $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git > to switch to GitLab (or edit your .git/config manually if preferred). > > I granted everybody access to the group https://gitlab.com/lilypond who > sent requests so far. Please make sure that your username is > recognizable to match with something that had access to SourceForge / > Savannah. If in doubt just send me a private email because there's no > possibility to reply to incoming access request from within GitLab. > > The general process stays in place, please push to staging instead of > directly to master. Whoever runs patchy, please update the > configuration as described above. > To open a merge request, there are two possibilities: either fork the > project or push a new dev/* branch directly to the repo and follow the > links. The label Patch::new should be added automatically. > > If you want to get emails for the project: GitLab has a notification > setting per project (little bell to the right of the project name). > "Watch" will notify you about everything (new issues, merge requests, > comments, ...), otherwise you can tick what you want with "Custom". > > So much for now. I expect us to figure things out as we go, and most > probably change some if suitable. > > Jonas Hi, currently I've very little time to work on LilyPond or to monitor the mailing-lists at all, thus I apologize if this is already answered elsewhere. For now I'll expect me getting familiar with GitLab very slowly... Nevertheless, I just did: $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git Next I wanted to do: $ git fetch returning: The authenticity of host 'gitlab.com (2606:4700:90:0:f22e:fbec:5bed:a9b9)' can't be established. ECDSA key fingerprint is SHA256:HbW3g8zUjNSksFbqTiUWPWg2Bq1x8xdGUrliXFzSnUw. Are you sure you want to continue connecting (yes/no)? What to do? $ git config -e reads [core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] url = g...@gitlab.com:lilypond/lilypond.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master [branch "dev/guile-v2-work"] remote = origin merge = refs/heads/dev/guile-v2-work [branch "stable/2.20"] remote = origin merge = refs/heads/stable/2.20 [branch "staging"] remote = origin Which looks ok, afaict. Thanks, Harm
Re: repository at GitLab
Am Montag, den 11.05.2020, 15:00 +0200 schrieb David Kastrup: > Jonas Hahnfeld writes: > > Am Montag, den 11.05.2020, 14:54 +0200 schrieb David Kastrup: > > > Jonas Hahnfeld writes: > > > > 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. > > > > This will create a branch starting with issue number, no big magic > > though. > > > > > 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. > > > > Instead you may put a "Closes #" into the last of your commits. > > This will automatically link the MR and even close the issue once the > > commits hit master. > > It would appear that the merge request now is listed as "linked" in the > issue, possibly because of a comment I posted referencing it. > > Issue numbers are recognised with # syntax in general? Yes, here's the full list of references: https://docs.gitlab.com/ee/user/markdown.html#special-gitlab-references For us, issues (#) and MRs (!) are likely the most important. Jonas signature.asc Description: This is a digitally signed message part
Re: repository at GitLab
Jonas Hahnfeld writes: > Am Montag, den 11.05.2020, 14:54 +0200 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > 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. > > This will create a branch starting with issue number, no big magic > though. > >> 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. > > Instead you may put a "Closes #" into the last of your commits. > This will automatically link the MR and even close the issue once the > commits hit master. It would appear that the merge request now is listed as "linked" in the issue, possibly because of a comment I posted referencing it. Issue numbers are recognised with # syntax in general? -- David Kastrup
Re: repository at GitLab
Am Montag, den 11.05.2020, 14:54 +0200 schrieb David Kastrup: > Jonas Hahnfeld writes: > > 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. This will create a branch starting with issue number, no big magic though. > 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. Instead you may put a "Closes #" into the last of your commits. This will automatically link the MR and even close the issue once the commits hit master. Jonas signature.asc Description: This is a digitally signed message part
Re: repository at GitLab
Jonas Hahnfeld writes: > Am Montag, den 11.05.2020, 14:22 +0200 schrieb David Kastrup: >> David Kastrup writes: >> > Jonas Hahnfeld 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
Re: repository at GitLab
Am Montag, den 11.05.2020, 14:22 +0200 schrieb David Kastrup: > David Kastrup writes: > > Jonas Hahnfeld 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
David Kastrup writes: > Jonas Hahnfeld writes: > >> Am Montag, den 11.05.2020, 12:44 +0200 schrieb David Kastrup: >>> Jonas Hahnfeld writes: >>> > Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup: >>> > > Jonas Hahnfeld < >>> > > hah...@hahnjo.de >>> > > > writes: >>> > > > Everything went pretty much as expected, so here's the repo: >>> > > > >>> > > > https://gitlab.com/lilypond/lilypond >>> > > > >>> > > > If you already have a local repository cloned from Savannah, execute >>> > > > $ git remote set-url origin >>> > > > g...@gitlab.com >>> > > > :lilypond/lilypond.git >>> > > > to switch to GitLab (or edit your .git/config manually if preferred). >>> > > >>> > > Wouldn't that just be readonly access? >>> > >>> > It has updated both for me, probably because I used SSH for both fetch >>> > and push. >>> >>> 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. I now try figuring out where my merge request ends up > and how it can be found and treated from the web interface. > > It probably should be a project-wide setting to have > merge_request.target=staging as default? > >> 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. -- David Kastrup
Re: repository at GitLab
Jonas Hahnfeld writes: > Am Montag, den 11.05.2020, 12:44 +0200 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup: >> > > Jonas Hahnfeld < >> > > hah...@hahnjo.de >> > > > writes: >> > > > Everything went pretty much as expected, so here's the repo: >> > > > >> > > > https://gitlab.com/lilypond/lilypond >> > > > >> > > > If you already have a local repository cloned from Savannah, execute >> > > > $ git remote set-url origin >> > > > g...@gitlab.com >> > > > :lilypond/lilypond.git >> > > > to switch to GitLab (or edit your .git/config manually if preferred). >> > > >> > > Wouldn't that just be readonly access? >> > >> > It has updated both for me, probably because I used SSH for both fetch >> > and push. >> >> 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. I now try figuring out where my merge request ends up and how it can be found and treated from the web interface. It probably should be a project-wide setting to have merge_request.target=staging as default? > Just added you (and all others that were in lilypond-trial) to the > lilypond group. Thanks. -- David Kastrup
Re: repository at GitLab
Am Montag, den 11.05.2020, 12:44 +0200 schrieb David Kastrup: > Jonas Hahnfeld writes: > > Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup: > > > Jonas Hahnfeld < > > > hah...@hahnjo.de > > > > writes: > > > > Everything went pretty much as expected, so here's the repo: > > > > > > > > https://gitlab.com/lilypond/lilypond > > > > > > > > If you already have a local repository cloned from Savannah, execute > > > > $ git remote set-url origin > > > > g...@gitlab.com > > > > :lilypond/lilypond.git > > > > to switch to GitLab (or edit your .git/config manually if preferred). > > > > > > Wouldn't that just be readonly access? > > > > It has updated both for me, probably because I used SSH for both fetch > > and push. > > 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... > remote: > remote: > > remote: > remote: You are not allowed to push code to this project. > remote: > remote: > > remote: > fatal: Could not read from remote repository. > > Please make sure you have the correct access rights > and the repository exists. Just added you (and all others that were in lilypond-trial) to the lilypond group. Jonas signature.asc Description: This is a digitally signed message part
Re: repository at GitLab
Jonas Hahnfeld writes: > Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > Everything went pretty much as expected, so here's the repo: >> > https://gitlab.com/lilypond/lilypond >> > If you already have a local repository cloned from Savannah, execute >> > $ git remote set-url origin >> > g...@gitlab.com:lilypond/lilypond.git >> > to switch to GitLab (or edit your .git/config manually if preferred). >> >> Wouldn't that just be readonly access? > > It has updated both for me, probably because I used SSH for both fetch > and push. 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 remote: remote: remote: remote: You are not allowed to push code to this project. remote: remote: remote: fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. -- David Kastrup
Re: repository at GitLab
>> Please give me access too; my username on GitLab is 'lemzwerg'. > > Done. Thanks! Werner
Re: repository at GitLab
Jonas Hahnfeld writes: > Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > Everything went pretty much as expected, so here's the repo: >> > https://gitlab.com/lilypond/lilypond >> > If you already have a local repository cloned from Savannah, execute >> > $ git remote set-url origin >> > g...@gitlab.com:lilypond/lilypond.git >> > to switch to GitLab (or edit your .git/config manually if preferred). >> >> Wouldn't that just be readonly access? > > It has updated both for me, probably because I used SSH for both fetch > and push. Ah, ok. I think I misread git:gitlab.com for g...@gitlab.com here. -- David Kastrup
Re: repository at GitLab
Am Montag, den 11.05.2020, 11:52 +0200 schrieb Jonas Hahnfeld: > Am Montag, den 11.05.2020, 11:39 +0200 schrieb Werner LEMBERG: > > > I granted everybody access to the group > > > https://gitlab.com/lilypond who > > > sent requests so far. > > > > Please give me access too; my username on GitLab is 'lemzwerg'. > > Done. > > > Another question is what to do with the lilypond git mirror on > > github... > > If we want to keep the mirror, we can make GitLab push updates > automatically as potentially discussed for Savannah. Sorry if I'm asking things I might have read if I had been able to pay closer attention recently. With the repository on Gitlab.com anybody who has an account can freely fork the repository and interact with that fork. (And from there then create Pull Requests to interact with the official repository.) If that's the case I don't think there's an actual need for a mirror on Github anymore. The original intention to set this up has been to enable people to work with the code without having to ask for permissions on the Savannah repository. My suggestion would be to disable that mirror by updating the README.md and archiving it (i.e. making it read-only). Urs > > Jonas
Re: repository at GitLab
Am Montag, den 11.05.2020, 11:39 +0200 schrieb Werner LEMBERG: > > I granted everybody access to the group https://gitlab.com/lilypond who > > sent requests so far. > > Please give me access too; my username on GitLab is 'lemzwerg'. Done. > Another question is what to do with the lilypond git mirror on > github... If we want to keep the mirror, we can make GitLab push updates automatically as potentially discussed for Savannah. Jonas signature.asc Description: This is a digitally signed message part
Re: repository at GitLab
Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup: > Jonas Hahnfeld writes: > > Everything went pretty much as expected, so here's the repo: > > https://gitlab.com/lilypond/lilypond > > If you already have a local repository cloned from Savannah, execute > > $ git remote set-url origin > > g...@gitlab.com:lilypond/lilypond.git > > to switch to GitLab (or edit your .git/config manually if preferred). > > Wouldn't that just be readonly access? It has updated both for me, probably because I used SSH for both fetch and push. signature.asc Description: This is a digitally signed message part
Re: repository at GitLab
Jonas Hahnfeld writes: > Everything went pretty much as expected, so here's the repo: > https://gitlab.com/lilypond/lilypond > If you already have a local repository cloned from Savannah, execute > $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git > to switch to GitLab (or edit your .git/config manually if preferred). Wouldn't that just be readonly access? -- David Kastrup
Re: repository at GitLab
> Everything went pretty much as expected, so here's the repo: > https://gitlab.com/lilypond/lilypond Congrats, and thank you very much for your hard work! > I granted everybody access to the group https://gitlab.com/lilypond who > sent requests so far. Please give me access too; my username on GitLab is 'lemzwerg'. Another question is what to do with the lilypond git mirror on github... Werner
repository at GitLab
Everything went pretty much as expected, so here's the repo: https://gitlab.com/lilypond/lilypond If you already have a local repository cloned from Savannah, execute $ git remote set-url origin g...@gitlab.com:lilypond/lilypond.git to switch to GitLab (or edit your .git/config manually if preferred). I granted everybody access to the group https://gitlab.com/lilypond who sent requests so far. Please make sure that your username is recognizable to match with something that had access to SourceForge / Savannah. If in doubt just send me a private email because there's no possibility to reply to incoming access request from within GitLab. The general process stays in place, please push to staging instead of directly to master. Whoever runs patchy, please update the configuration as described above. To open a merge request, there are two possibilities: either fork the project or push a new dev/* branch directly to the repo and follow the links. The label Patch::new should be added automatically. If you want to get emails for the project: GitLab has a notification setting per project (little bell to the right of the project name). "Watch" will notify you about everything (new issues, merge requests, comments, ...), otherwise you can tick what you want with "Custom". So much for now. I expect us to figure things out as we go, and most probably change some if suitable. Jonas signature.asc Description: This is a digitally signed message part
