[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GitLab | Projects forced to "Private" (#294196)

From: Chris Kuethe
Subject: Re: GitLab | Projects forced to "Private" (#294196)
Date: Thu, 17 Dec 2020 19:25:05 -0800

Indeed, my repo is also still "forked from an inaccessible project"

In terms of git hosting provider c*ck-ups lately, I think I now trust gitlab about as much as I trust sourceforge - as a place where I clone stuff from before I push it to github, or keep it in my own internal mirror infra (not a local instance of gitlab). Well, maybe a little bit more than sourceforge because at least it's git and not svn/cvs.

On Thu, Dec 17, 2020 at 7:02 PM Fred Wright <> wrote:

On Thu, 17 Dec 2020, Eric S. Raymond wrote:

> James Browning via devel <>:
>> The ntpsec forks belonging to rlaager, selsky, and ianbreune are still
>> detached. A quick check shows that there are no forks. The page I looked at
>> claimed that such detached repositories cannot be reattached. TLDR there is
>> only on MR that still might be mergeable.
> Annoying, but recoverable.

I'm not sure that is recoverable by users directly.  And the "if you broke
it, you fix it" rule ought to apply to the GitLab folks.  Fully recovering
from this requires:

1) Fixing the project visibility.

2) Undetaching all the erroneously detached forks.

3) Recovering (reopening?) all the erroneously closed merge requests.

4) ???

And this needs to be done for all affected projects.

It seems that they've only done #1 so far.  Both my gpsd and ntpsec forks
currently show as "Forked from an inaccessible project".  However, I have
two other GitLab forks that don't appear to have been affected, so it's
not *all* GitLab projects.

Fred Wright

GDB has a 'break' feature; why doesn't it have 'fix' too?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]