
A fork on GitHub is no fork - nielsole
https://www.niels-ole.com/ownership/2018/03/16/github-forks.html
======
snowwrestler
As someone who runs a bunch of private repos on Github, and hires freelancers
and vendors to work on them, I like the way Github manages forks of private
repos. When I end a relationship, and remove that person from my private repo,
I want their fork of my code to go away too.

Why? Because it's cleaner. It means there are no abandoned copies of my
codebase sitting around forever forgotten in random Github accounts. I set up
a private repo because I want to control access to my code. That's why a
private repo is private.

It also makes it harder for people to misrepresent their relationship to me
later on. Sure, anyone with read access to one of my repos can pull it down
and save a local copy. But that is different from logging into Github and
having a fork of my repo. A Github fork looks and works differently from a
local copy.

This whole situation seems weird because the idea of a "private" repo is not
inherent to how git was intended to work; it's something Github invented to
make money. So I'm not surprised that it violates people's expectations
sometimes.

~~~
secstate
But nothing is stopping them from cloning and pushing up to BitBucket or a
private git hosting service. You merely have the appearance of cleanliness
with none of the security.

The only way to really protect yourself is with a contract that stipulates the
repo and any clones a contractor may have access to must be destroyed upon
termination of the contract.

~~~
snowwrestler
This has nothing to do with security. Would you upload secrets into a private
Github repo? I wouldn't. Private repos are not more secure than public repos.

Github is a tool for collaboration. The point of a private repo is to manage
who you are collaborating with. Once I don't want to collaborate with someone
anymore, there is no reason for them to have a Github fork of my code anymore.
As I said, it's cleaner.

I'm fully aware that they can save a local copy (did you read my 3rd paragraph
above?), and of the importance of contracts.

~~~
andrewstuart2
Access control is 100% security. If you have a private GitHub repo, you have
uploaded secrets. All that code is your secret. You pay GitHub to protect all
the copies they know about, but you are fooling yourself if you rely on that
_after_ you've given access to that private repo away. You fundamentally can't
revoke knowledge, just future access.

~~~
snowwrestler
No, secrets are pieces of information that you could use to compromise my
production environment--like passwords or private keys. Those should never be
uploaded to Github, period.

~~~
andrewstuart2
You're talking about credentials. Secrets are often credentials, but more
generally refer to anything confidential.

~~~
onenite
Code doesn’t necessarily have to be confidential. “Secret recipe” algorithms,
maybe.

It’s about trade-offs. If you must have “trade secrets” amongst your code,
perhaps you can keep that code available only to whom you trust will follow
your wishes with it, and have separate repos to share wherein you do not care
as much about collaborators “stealing” the code.

As soon as you let someone into your codebase, almost anything can happen,
right?

There are cases where it would make sense to sacrifice risks related to code-
copying in order to have faster/better development.

Also, what’s stopping anyone working at ANY company from taking the company
code and doing whatever they want?

Code is seldom everything.

------
Arqu
The author states that he didnt bother with support (luckily he had a local
copy) so here are my 2 cents

I've been in the exact same spot under very similar circumstances. What I can
add is that the github support was great, we got it resolved within the
working day.

The repo was "deleted" to free up the private repos of my colleague but we
didnt know that the fork on my account would go down with it. Its been
probably a couple months till we got back to it and noticed the issue. They
managed to recover the repo and unblock my fork. I just did a fresh repo and
moved everything over.

While it is odd behavior, if its really bad they will probably manage to get
you back on your feet.

Also Im not affiliated with github in any way just have some repos from
student days over there. If it matters im on gitlab and google repos

~~~
newsat13
So they keep copy of code after it's deleted?

~~~
Sir_Substance
In their business-continuity backups, you'd have to assume yes.

However, I would certainly be surprised if a Github support staff member went
and fished out the off-site backup and mounted it to recover one missing repo.
You'd hope that would require quite a few staff members to orchestrate.

But in general, yeah. Most engineers don't think about deletion very hard when
they start designing a system, and it's also convenient (although with GDPR
possibly soon illegal, situation dependent) for auditing and research to
merely flag things as deleted and not show them to the customer. As a result,
true data deletion generally gets justified away as a bit inconvenient and not
really desirable anyway, and almost no software company really deletes
anything on demand. Best you can hope for is semi-annual data purges to
reclaim disk space.

If this bothers you, consider joining us in the world of self-hosting your
services. Gitlab is in my opinion considerably better than Github anyway.
Certainly it's worth spinning up a docker container and taking a peek around.

------
inetknght
> _this taught me not to rely on Github as only storage for code_

If you didn't already know this, then... good lesson to learn.

Just like backups: don't rely on a single source of _anything_.

~~~
paulgb
Has anyone created a service that you auth in through GitHub and it backs up
all your repos to S3 or Dropbox or something? I'd pay a few bucks for
something like that.

Edit: I found backhub.co. Unfortunately their pricing is per-repo and my usage
model involves lots of tiny repos.

~~~
rplnt
Set multiple urls for one remote using `--push`

[https://git-scm.com/docs/git-remote#git-remote-emset-urlem](https://git-
scm.com/docs/git-remote#git-remote-emset-urlem)

and you are about done.

~~~
synctext
This is only a partial solution, right? Services such as Backhub.co also
backup your issues: [https://backhub.co/features/backup-github-
issues/](https://backhub.co/features/backup-github-issues/)

(we have 1000+ closed issues in our project, nice to preserve)

~~~
rplnt
Right. The service is certainly expected to do more. Was mostly addressing the
issue of mirroring the data to dropbox. But even then my "solution" only saves
whatever you do locally. So if you merge PRs through github, it wouldn't get
mirrored.

------
kylecordes
Some of the strain here is around two very different meanings of the word
"fork", but only a single feature with that name on GitHub:

1) When I want to contribute to a project, make some local changes and offer
them back to the mainline, I fork. My fork is a pseudo-throwaway thing; it
contains code that is hopefully destined either to make it back to mainline,
or likely to be abandoned if mainline moves on in active development.

2) When I want to go my own way with a project, using it as a starting point
for a new direction of development that may wander in a direction quite far
from the original (it might get renamed, it might continue development of the
original becomes abandoned, etc.), I also fork.

Numerically meaning 1 is surely far more common, so it makes sense for the
GitHub features and permissions etc., to optimize for that case.

Meaning 2 is closer to the original idea of a fork, from open source
vernacular long predating GitHub.

Naming is hard, and I don't blame them for picking a single name for these two
technologically similar (but socially different) scenarios.

~~~
styfle
I don’t think GitHub actually labels #2 as a fork, but traditionally that’s
been the meaning.

They just needed a word to show that the repo is not original and is tied to
an upstream repo.

For example, when I wanted to “fork” a project[0] that was no longer
maintained and not accepting PRs, I actually had to contact GitHub to “unlink”
my repo so that I my repo could be standalone and utilize all the features on
GitHub (can’t remember which features off the top of my head).

[0]: [https://github.com/styfle/geoslack](https://github.com/styfle/geoslack)

~~~
brianpan
I think you're right. So my conclusion is....a fork on GitHub is no fork.

------
MattyRad
I forked Popcorn Time when it came out, just because I was impressed with the
app and I wanted to look over (and possibly modify) the code. I only forked in
though, I didn't clone it locally. A week later when I had some free time to
do so, same issue, my personal fork disappeared. It was mildly aggravating,
but also a soft reminder to question how much trust to put into third-parties.

~~~
dspillett
I wouldn't call it a trust issue, but a due diligence one: making sure you do
enough to ensure anything you care about is safe.

In this instance making sure that you understand the service you are using
(including intricacies like this), _or_ keeping an extra backup of your own (a
locally cloned copy of the repo), _or_ for proper paranoia, both of the above.

No matter how much you trust github and those in positions of responsibility
for the projects you interact with, if you don't know the exact details of the
feature-set you can come unstuck due to operating under false impressions.
Github has done nothing wrong, as that is how the service is intended to work
and it is documented as such (though it would appear some of the documentation
is incorrect or at least inconsistent?), but you still get an inconvenient
surprise because of a misunderstanding.

A little paranoia can be very useful!

~~~
snugghash
I'd argue this is barely worth the time spent. You'd use at least a hundred
services of this sort, with a flux of at least one a week. 2-3 hours reading
up on intricacies, setting up backups for your data? It's a crazy amount of
time to spend on something you _dont_ care about - you just want it to work.

~~~
dspillett
If argue that if you care enough about the content that you'll do more than
say "oh well" to yourself if it becomes inaccessible, then researching this
sort of thing or (probably easier but maybe more costly in terms of bandwidth
use) rigging it up to your existing backup infrastructure is the minimum
effort you did make. If you don't you have no high ground from which to
complain or blame others from if it going away inconveniences yourself.

If you don't care about it that much, why do you keep it anyway?

------
kenrick95
Well, it is stated on the help page, regarding private repositories and its
fork: [https://help.github.com/articles/what-happens-to-forks-
when-...](https://help.github.com/articles/what-happens-to-forks-when-a-
repository-is-deleted-or-changes-visibility/)

> _Private forks inherit the permissions structure of the upstream or parent
> repository._

~~~
nielsole
Ah, thanks for pointing me to it. I still find the behaviour unintuitive, but
at least it is documented somewhere.

------
bhauer
> _Luckily I found an old local copy of my project, but this taught me not to
> rely on Github as only storage for code._

This is the distillation. If something matters to you, you should personally
take responsibility for its long-term storage. Apparently for the author,
finding a true duplicate was just luck. To minimize the risk, maintain
multiple copies on multiple media. Github is only one medium.

The context is especially notable: this is source code and source code is (in
a majority of cases) very small. Maintaining personal archives of project
source is a comparatively simple and low-cost matter.

~~~
gkya
How reliant people are on Github is puzzling. If Github somehow failed one
day, many businesses and OSS projects would just fail to operate. What
surprises me is that software teams in companies use it too, when just sending
commits/patches around is quite easy with any VCS.

~~~
katastic
Kind of like how that one NPM package took down like 14,000 other packages
when someone took a DMCA request against an author's OTHER package and he just
took them all down in protest--which took down their dependencies and their
dependencies and ... "broke the world".

[https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/](https://www.theregister.co.uk/2016/03/23/npm_left_pad_chaos/)

The code in question was like 11 lines of code (with curly and spaces!!) for
calculating left-hand padding for a syntax highlighting code box.

------
AdmiralAsshat
Does this apply to public repos?

I have a close friend who past away a few months ago, and wanted to try to
find some way to preserve all of his GH repos for his wife and children. I've
locally cloned all of them, but the prospect that GH might delete all of his
stuff if he fails to login for a certain amount of time or something is deeply
concerning.

I don't suppose GH has some kind of memorial/preservation mode the way
Facebook does?

~~~
icebraining
"Inactive accounts may be renamed or removed by GitHub staff at their
discretion."

[https://help.github.com/articles/name-squatting-
policy/](https://help.github.com/articles/name-squatting-policy/)

There are a few blog posts of people who got GH support to release the names
of inactive accounts, though it's not clear if those accounts had any repos at
all.

------
johndbritton
Hey Niels!

I'm John, and I work at GitHub. Sorry to hear you're having difficulty.

From your post:

> I haven’t tried contacting customer support, but as this appears to be
> official policy I would not expect a change there.

I'd recommend you reach out to support@github.com, they're usually very
helpful with things like this.

~~~
nielsole
Hey John,

thanks for reaching out. The individual case was resolved (found a local
copy). But I find the policy worrisome for future projects. If the customer
support was happy to reenable access for me, what is the point of the current
policy?

~~~
crankylinuxuser
That's why I've been migrating my Github/lab projects to IPFS as well. I have
a few cheap VPSes I have my stuff pinned.

"Cloud" (read: someone else's server) is unreliable at best, or malicious at
worst like this case. The people may not be bad actors, but the tech
definitely is.

~~~
bringtheaction
Would like to hear more about your git with IPFS workflow.

------
cdancette
I think the last sentence may be wrong

> I haven’t tried contacting customer support, but as this appears to be
> official policy I would not expect a change there.

I'm sure the support would be able to do something for you there, anyway it's
always good to contact them, even if they can't do anything, before saying
things like this online.

~~~
alex_hitchins
I disagree. People need to be aware of this before it becomes an issue for
them. Git is distributed and yes, relying on one resource is a risk in itself,
however - if a fork isn't a fork it should be made clear.

~~~
cdancette
yes but the point is he didn't even ask the support so his claims are just
wrong. Maybe the support will always replace your fork with a copy if you just
ask.

I agree the UX is bad though and should be improved

~~~
alex_hitchins
My point is he shouldn't have to ask support to let him have access to
something he took a fork of. Bad UX aside, a fork allows one to think of a
permanent branch that is distinct from the original. This is not the case.

------
zimbatm
Related to that: if a private repo is forked, the target account doesn't need
a paying subscription. In that sense, it's the root repository holder that is
paying for the new private repo.

I'm not arguing if it's a good or bad thing, it just seems consistent in that
regard.

------
pandler
At least on Bitbucket they're pretty explicit about the rules around forks.
Creating a new private repository, you get the option to select [No Forks |
Allow Forks | Allow only private forks]. I don't see any kind of configuration
like that on github.

~~~
dfansteel
Does that differentiation necessarily mean Bitbucket repos are immune to this
problem?

~~~
pandler
No of course not. They're just a bit more explicit about the fact that
permissions can persist across forks.

------
jrochkind1
Apparently there's no github web UI to actually copy a repo so it's not listed
as a fork, but of course git makes it quite possible, and github even provides
directions, using git directly.

[https://help.github.com/articles/duplicating-a-
repository/](https://help.github.com/articles/duplicating-a-repository/)

I'm imagining a browser plugin that notices when a repo you are about to fork
is private, and (or even without that) adds a 'copy' button which gives you
text to copy-and-paste into your terminal to make a true copy.

------
tracker1
On the one hand, it bugs me when I see a repo that was obviously cloned/forked
from another REPO and uploaded new without the github (fork) link to the
original... but upon seeing this, I many have to reconsider doing that with a
few repositories.

When I left a prior job, I forked and took over updates of a relatively
popular open-source library under my own GH account... I'd hate to see it all
disappear because someone from a former job decides to nuke the upstream repo.

------
hashkb
In the alternative case, a company who terminates an engineer can't prevent
them from accessing the code if they've forked it. This is a"problem" with
git, which GitHub has tried to solve for its paying customers. Whether or not
you agree... GitHub has worked like this for years.

~~~
Someone1234
If GitHub wants to implement DRM-like copy control, they should implement
actual DRM-like copy control, and leave fork the heck alone.

Part of the problem is that instead of being explicit about how things work
they're being implicit. Instead of users being told a fork is not a, you know,
fork they're lied to only to have the fork vanish later.

Why is there no banner at the top of the repo warning you this is a fake repo?
Why is there no ability for the original owner to delegate a full fork to the
children? If this implemented this correctly you'd expect to have control over
how it works (or turn it off).

------
Ne02ptzero
I think a fork is just an internal branch on the original repositoriy for the
Github Servers. From a data / sys admin point of view, it makes sense, since a
hard-copy of a repository (and all the git objects with it) is just generally
useless.

~~~
Nerdfest
I would guess that it's stored and dealt with using a basic "copy on write"
strategy. It's functionally a copy, which is all that usually matters. This
may have been an oversight.

~~~
philipwhiuk
It's a bit more complex than that actually.
[https://www.youtube.com/watch?v=-ZNKR9wFe8o](https://www.youtube.com/watch?v=-ZNKR9wFe8o)

------
fouc
A possible workaround?

Fork a private repo. Make it public, thus forcing a new repository network to
be made. Then take it private again if you choose.

In the case of a public fork, it seems you're safe from it getting taken out
from you. (relatively speaking)

~~~
Someone1234
The fact you have to do this to make a fork, fork, is problematic. You could
also download the fork, and then upload it again as a new root, but in both
cases it entirely defeats the point.

A lot of people are coming up with workarounds or blindly defending Github in
this thread. I think I'm the only way that sees this decision was done for
commercial reasons ($), and has nothing to do with people "maintaining control
of their private repo."

Frankly if fork doesn't, you know, fork due to some quirk in some random
article you aren't going to read or find that to me is a massive black mark
against Github. That's all I care about, Github working like Git, in most
major ways.

~~~
ben509
`I think I'm the only way that sees this decision was done for commercial
reasons ($)...`

Is it fair for me to expand "for commercial reasons" as:

Github is a for-profit business, and their business model is to provide a
service to users and that also requires them to be able to turn that service
off when customers stop paying.

`... and has nothing to do with people "maintaining control of their private
repo."`

I disagree here, I think you're using a notion of "control" that is too
narrow. A notion that captures the scope better would be that Github is adding
value by enabling project management and collaboration. The ability to do pull
requests, manage issues, etc. is all tied to forking.

That's what makes their service worth paying for, and it's also what they have
to turn off if you don't want to pay.

`That's all I care about, Github working like Git, in most major ways.`

What you're saying here is reasonable enough I expect you can find providers
that are pretty close to that standard, and it's a fair point that Github's
business model has some sharp edges. In this case, it's a consequence of "we
turn the lights off if you don't pay," and an alternative has to deal with the
same bottom line.

------
masklinn
[https://blog.github.com/2015-07-02-greater-control-over-
fork...](https://blog.github.com/2015-07-02-greater-control-over-forks-of-
your-private-repositories/)

------
Nokinside
>GitHub has the right to suspend or terminate your access to all or any part
of the Website at any time, with or without cause, with or without notice,
effective immediately. GitHub reserves the right to refuse service to anyone
for any reason at any time.

Companies write these "We are can do whatever" clauses to license agreements
so that they can point to them and make people go away.

IANAL, but EULA terms like are typically in breach with Consumer Law
protections against unfair contract terms. If you are private person
(consumer) paying for a service, this kind of term may be null and void.

------
EdSharkey
So it sounds like active links between forks is intended to mirror the valid
links between people/organizations that are doing business with one another.
If people or organizations end their relationship, then there's a way to
cutoff any secondary contributors to the codebase to have the ability to make
pull requests from -and- receive code updates.

At first blush, I thought, "GitHub is mean and just locking-in their paying
customers forever!!" But now after reading the comments here, I think this is
a very pretty way to represent the nuances of a fork relationship.

If the original owners of a private codebase disappear, then it is reasonable
and just that all of the forks to their code should as well. I believe it's
reasonable and just because GitHub have no way to interpret _why_ the original
owner dropped off and must respect their ownership by breaking the
relationship.

------
jbfoo
You might use gitlab to clone your github repos. Web interface to clone them
is super easy (obviously you can do it from the console also), there is no
limit to private repos (their business model seems to be charging for CI time
and selling on-premise licenses).

I'm not affiliated with either hosting services and I use both :)

------
urda
Backups, backups, backups, BACKUPS.

Don't rely on GitHub being your only source location. Git is a DVCS, meaning
you don't have to have a single upstream. Make sure you are pushing /
mirroring to a third party (GitLab, Bitbucket, personal Git Server, etc)

~~~
kardos
Do you know a good way to automate that?

~~~
philipwhiuk

      $ vi /usr/bin/gpa
      #!/bin/bash
      git push github $?
      git push bitbucket $?
      $ gpa

------
Ilyes512
This really sucks... I know companies that made forks of public (opensource)
repo's just to have a "backup" in case the person or organisation decides to
take down the repo. This should really be fixed as I don't see ANY benefit in
the current way github handles this now. People talking about giving
contractor's or other third party people access to later revoke them (after
they are done) thinking they wont have a copy, are just plain simple wrong.
Git is decentralised and the contractor/dev will always have his code on his
machine unless HE decides to delete it.

------
thriftwy
Just yesterday on HN I was recommended of git-ssb.

I think it's time.

------
peteey
Is fork part of git? I don't see it mentioned in the official documentation:
git-scm.com

Fork seems like some feature cloud storage services invented.

~~~
Gaelan
The terminology is a GitHub-and-friends thing, but the idea is at the core of
git. When you clone a repository, you're creating a "fork" of the repo on your
own computer. Git is a DVCS (distributed VCS), where you can make many
copies/forks of a repository and freely push/pull commits between them. (As
opposed to something like SVN, where the repository lives on a single server,
and all commits go directly to that server without a separate "push" step.)

~~~
chungy
The terminology is at least a couple decades older than GitHub has even
existed, and was even mentioned somewhere by Linus in the creation of Git.

Fork used to have a very negative connotation, and that was related to the
difficulty required to pull one off. When you forked a project, you had to set
up your own hosting, web space, issue tracker, version control system (and you
probably couldn't clone and start off the upstream's VCS), and so forth. The
technical barrier made it so that you only forked a project when you have
severe disagreements with upstream; some of the most famous in history include
EGCS from GCC, and XEmacs from Emacs.

With DVCSes, including Git, much of that technical difficulty is automatically
removed. Every clone can potentially be a fork (as in, a new independent
project), and this was one of Linus's intentions. If forking is easy, it keeps
upstream on their toes. After being adopted by DVCS hosting sites like GitHub,
it turned around to being a positive term even.

------
gkya
I observe that people "fork" repositories (which is basically a cheap clone
rather than a fork, bad terminology there) not for having a copy of their own
to work on, but more like a glorified "like/+1/star". So even with public
repos, it seems quite acceptable that Github tries to deduplicate
aggressively.

------
discordianfish
This is also simply to their per private repo pricing model. You can fork
private repos with a free account. I'd just ask github support about this
particular issue and I'm pretty sure they'll can either make the repo open or
at least make the code available to you somehow.

------
greggman
This is no different than Google Docs and many other similar services. If you
share a Google Doc with someone it will show up in their list of Docs. But it
is just a reference to "their" doc. If they delete the doc there's no doc to
reference and your "apparent" copy of the doc (which was really just a
reference) disappears.

If you really wanted your own personal copy you need to make a duplicate. That
duplicate will be yours not a reference to theirs.

It was strange the first time I ran into it. I deleted an account. I had
shared the documents with another account of mine. Then I noticed when I
deleted the first account I lost access to those docs. Now I know I hadn't
copied the docs I'd only had references to them. Next time I'll know to make
copies if I actually want copies and not just access to another account's
shared docs.

------
IAmEveryone
This seems to be an edge case, affecting only private repositories. I can see
how this can make sense in that context. Can we do without the pitchforks?
(pun intended)

~~~
ahnick
It still doesn't make sense in that use case. He could have cloned it to his
local machine and still had access to the code. Had he done that he could have
pushed it back to github as a completely new repository thereby creating a
legitimate fork. It's a silly requirement from github.

------
tokenizerrr
Did you contact GitHub regarding this and ask them, before bashing them on
social media? What was their response? They'll probably gladly remedy the
situation.

~~~
nielsole
> Luckily I found an old local copy of my project [...] I haven’t tried
> contacting customer support, but as this appears to be official policy I
> would not expect a change there.

The policy itself needs to be changed, the individual case is resolved.

~~~
tokenizerrr
Or the policy was misinterpreted. The piece of text that got quoted is present
in every single EULA ever and does not at all indicate if this is actually
intentional by GitHub.

Besides, you can request to disconnect your fork from an upstream project. I
expect such a request will also resolve this problem.

------
nlo
If you want a _mirror_ of a repository, self hosted Gogs/Gitea is a great way
to do this in a way that makes you unbeholden to the upstream.

------
hartator
Hum, I would think it’s to avoid spreding of private company repositories when
employees get terminated. It does make sense.

------
cup-of-tea
Git is a distributed version control system and Github is not in a privileged
position. Don't treat it like it is. Github is a convenience. Nothing more.

"Forks" are really just branches and branches are really just references.
Forking just adds a few more references to the same repository.

~~~
jeremiep
You realize that implementing forks as branches creates a LOT more work for
Github to make it work? It makes absolutely no sense for them to do so.

A copy-on-write fork is most likely what is being implemented.

~~~
cup-of-tea
What do you mean? What's the difference between a fork and a branch? It's not
copying anything.

------
HIPisTheAnswer
And this is why I dont have a github account. One day, all those foolish users
will be left hanging, crying for the dust which has replaced their code and
CI. The deserve worse; they have enabled this central organization to subvert
the heart of OSS. May github go down forever, along with google translate and
all those other projects which have crippled our technical progress.

------
gaius
Git is a DVCS, this is only an issue if you use it as if it were a traditional
VCS.

~~~
dboreham
Which is how almost everybody uses it, so not such a helpful observation.

~~~
megous
Unless people are doing shalow clones, almost everybody uses git as DVCS.

~~~
magila
There's a little more nuance to it than that. While git users generally keep a
local copy of a repo, collaborating with others is pretty much always done
through a central server. Git users could theoretically collaborate without a
central server, but it currently a far too manual process to be considered
practical. There were a couple of attempts to implement decentralized
collaboration in git under the name gittorrent, but those didn't go anywhere.
Failure is understandable in this space, decentralized collaboration is a
_hard_ problem and the tools to do it are still in their infancy. IPFS is
probably the furthest along at this point and they're still a long ways away
from having something production ready.

~~~
megous
Sure, but it's decentralized in a sense that there's nothing special about any
of the clones. If developers lose their shared clone of the repository, they
can re-create it easily by seting up another shared clone that anyone can
access and push there from their local repos. Nothing will be lost.

"Central" server is not special in any way, other than being readily
accessible by everyone in the team.

Some services break this by piling other stuff on top of git that's not
distributed (like issues, ci, etc.), but that's not a problem of git.

~~~
magila
But in most people's workflows there _is_ something special about the central
server: it is the source of truth about the state of public branches. That is
why losing the central server is so disruptive. It means you have to re-
establish the source of truth somewhere else and get everyone to transition
over to that new source.

With a truly decentralized system the source of truth would be content
addressable. For example, it could be obtained via a public key rather than a
server's domain name.

------
Laaas
Well, I mean, what did you expect? You'd be able to cheat the system
otherwise.

~~~
u801e
What if I just cloned the repo, created a repo of the same name under my own
account and then pushed up my local clone to the new repo?

~~~
huslage
Nothing is stopping you from doing that. The preferred experience is not to do
it though.

~~~
u801e
I should have completed my question in my earlier post. Specifically, would
doing that instead of creating a fork through Github's interface prevent one
from losing access to their project when the previous copy is deleted from
Github?

~~~
BeeOnRope
Yes.

