Re: [gpsd-dev] Upcoming migration to GitLab

[Fred Wright]

On Sun, 26 May 2019, Eric S. Raymond wrote:
> Hal Murray <address@hidden>:
> > address@hidden said:
> > > > Strange.  Can anyone else get at it?
> > > Works for me:
> > > # git clone address@hidden:gpsd/gpsd.git
> >
> > address@hidden xxx]$ git clone address@hidden:gpsd/gpsd.git
> > Cloning into 'gpsd'...
> > > GitLab: You are not allowed to download code from this project.
> > fatal: Could not read from remote repository.
>
> I just enrolleed you as a developer. See if you can clone now?

You don't need to clone to test.  Fetch is sufficient, and quite fast when 
fetching into a repo that already contains the content.  See the examples 
from my earlier post.

> I'm a bit puzzled.  The project visibility is definirely "public".

Did you do something to make Fork and Clone appear?  Because they did, and 
I successfully forked the repo (though the fork count on the webpage is 
stale).  I now have:

MacPro:gpsd fw$ git remote -v
main    ssh://git.sv.gnu.org/srv/git/gpsd.git (fetch)
main    ssh://git.sv.gnu.org/srv/git/gpsd.git (push)
origin  address@hidden:fhgwright/gpsd.git (fetch)
origin  address@hidden:fhgwright/gpsd.git (push)
upstream        address@hidden:gpsd/gpsd.git (fetch)
upstream        address@hidden:gpsd/gpsd.git (push)

On Sun, 26 May 2019, Eric S. Raymond wrote:
> Fred Wright <address@hidden>:
> > > Ah, OK. We *are* going to have to turn off mitroring before it can be forked, 
> > > then.
> > > I didn't know that - haven't done this before.
> >
> > So that should be done sooner rather than later.
>
> Not seeing it. Seems to me that's exactly the thing to be done on cutover day.
> Check that the repos are in sync, then turn off mirroring.

This was about making forking available sooner rather than later, though 
it seems to have already happened somehow.

> > Oh, it's *certainly* not necessary to resort to format-patch and am in any
> > case.  One can always copy commits from one repo to another via fetch and
> > push, with a rebase in between if needed.  No need to resort to error-prone
> > and lossy patch files.
>
> One can always...if one has CLI access to the host on the fetch end.  Here
> we don't, we have to work via the GitLab web interfaces and pushes.  But as
> I said, I'm not worried.  I've done this sort pf thing before; ve haff vays.

Huh?  You only need CLI access to *your own computer* (or perhaps some GUI 
tool that I've never used).  You can copy any branch of any readable repo 
to any branch of any writable repo with:

        git fetch source_repo source_branch:local_branch
        git push dest_repo local_branch:dest_branch

Each of these steps assumes that the target branch is either nonexistent 
or fast-forwardable.  Rebasing can be inserted in between if needed.

If you don't want to keep local_branch, then:

        git branch -D local_branch

> > No problem here:
> >
> > MacPro:gpsd fw$ git fetch address@hidden:gpsd/gpsd.git master:test
> > > From gitlab.com:gpsd/gpsd
> >  * [new branch]          master     -> test
> > MacPro:gpsd fw$ git branch -D test
> > Deleted branch test (was c0a78c2d2).
> >
> > But I don't see Sanjeev in the member list, which may even matter for reads
> > (see below).
>
> Sanjeev, I just added you as a guest.  Now try cloning?

Or just fetching, as in the example above.

> > I expect that the intent is for this repo to be publicly readable, but that
> > doesn't currently appear to be the case.  It seems somewhat unlikely that
> > this property would be tied to "mirrorness", so perhaps the Fork/Clone issue
> > isn't, either.
>
> Too little data.  I think the picture's going to change when we de-mirror
> it and am thus not really interested in chasing edge cases in how it works
> now.

It seems to have changed already. :-)

Fred Wright