repository at GitLab

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

repository at GitLab

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 [hidden email]: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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

Werner LEMBERG

> 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

Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

David Kastrup
In reply to this post by Jonas Hahnfeld
Jonas Hahnfeld <[hidden email]> 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 [hidden email]:lilypond/lilypond.git
> to switch to GitLab (or edit your .git/config manually if preferred).

Wouldn't that just be readonly access?

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

Jonas Hahnfeld
Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup:
> Jonas Hahnfeld <[hidden email]> 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
> > [hidden email]: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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

Jonas Hahnfeld
In reply to this post by Werner LEMBERG
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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

Urs Liska-3
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


Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

David Kastrup
In reply to this post by Jonas Hahnfeld
Jonas Hahnfeld <[hidden email]> writes:

> Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld <[hidden email]> 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
>> > [hidden email]: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 [hidden email] here.

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

Werner LEMBERG
In reply to this post by Jonas Hahnfeld
>> Please give me access too; my username on GitLab is 'lemzwerg'.
>
> Done.

Thanks!


   Werner

Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

David Kastrup
In reply to this post by Jonas Hahnfeld
Jonas Hahnfeld <[hidden email]> writes:

> Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld <[hidden email]> 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
>> > [hidden email]: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

Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

Jonas Hahnfeld
Am Montag, den 11.05.2020, 12:44 +0200 schrieb David Kastrup:

> Jonas Hahnfeld <[hidden email]> writes:
> > Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup:
> > > Jonas Hahnfeld <
> > > [hidden email]
> > > > 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
> > > > [hidden email]
> > > > :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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

David Kastrup
Jonas Hahnfeld <[hidden email]> writes:

> Am Montag, den 11.05.2020, 12:44 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld <[hidden email]> writes:
>> > Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup:
>> > > Jonas Hahnfeld <
>> > > [hidden email]
>> > > > 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
>> > > > [hidden email]
>> > > > :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

Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

David Kastrup
David Kastrup <[hidden email]> writes:

> Jonas Hahnfeld <[hidden email]> writes:
>
>> Am Montag, den 11.05.2020, 12:44 +0200 schrieb David Kastrup:
>>> Jonas Hahnfeld <[hidden email]> writes:
>>> > Am Montag, den 11.05.2020, 11:42 +0200 schrieb David Kastrup:
>>> > > Jonas Hahnfeld <
>>> > > [hidden email]
>>> > > > 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
>>> > > > [hidden email]
>>> > > > :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

Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

Jonas Hahnfeld
Am Montag, den 11.05.2020, 14:22 +0200 schrieb David Kastrup:

> David Kastrup <[hidden email]> writes:
> > Jonas Hahnfeld <[hidden email]> 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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

David Kastrup
Jonas Hahnfeld <[hidden email]> writes:

> Am Montag, den 11.05.2020, 14:22 +0200 schrieb David Kastrup:
>> David Kastrup <[hidden email]> writes:
>> > Jonas Hahnfeld <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

Jonas Hahnfeld
Am Montag, den 11.05.2020, 14:54 +0200 schrieb David Kastrup:

> Jonas Hahnfeld <[hidden email]> 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 #<num>" 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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

David Kastrup
Jonas Hahnfeld <[hidden email]> writes:

> Am Montag, den 11.05.2020, 14:54 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld <[hidden email]> 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 #<num>" 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 #<num> syntax in general?

--
David Kastrup

Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

Jonas Hahnfeld
Am Montag, den 11.05.2020, 15:00 +0200 schrieb David Kastrup:

> Jonas Hahnfeld <[hidden email]> writes:
> > Am Montag, den 11.05.2020, 14:54 +0200 schrieb David Kastrup:
> > > Jonas Hahnfeld <[hidden email]> 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 #<num>" 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 #<num> 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 (#<num>) and MRs (!<num>) are likely the most important.

Jonas

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

Thomas Morley-2
In reply to this post by Jonas Hahnfeld
Am Mo., 11. Mai 2020 um 09:14 Uhr schrieb Jonas Hahnfeld <[hidden email]>:

>
> 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 [hidden email]: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 [hidden email]: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 = [hidden email]: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

Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

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 [hidden email]: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 (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: repository at GitLab

Thomas Morley-2
Am Di., 12. Mai 2020 um 08:32 Uhr schrieb Jonas Hahnfeld <[hidden email]>:

>
> 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 [hidden email]: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

12