[tahoe-dev] github plan?

[Brian Warner]

>> On 03/03/13 16:12, Greg Troxel wrote:
>>> 
>>> I have a repo cloned from "warner", and so do a lot of others,
>>> but now it seems like the tahoe-lafs organization account is
>>> the official repo. So I am wondering if I (and everyone else
>>> cloned off warner@), and maybe even Brian's repo, should remove
>>> them and re-fork off the official one.
>>> 
>>> https://github.com/warner/tahoe-lafs/network/members
>> 
>> If Brian's repo re-forked, would that would disrupt viewing the 
>> history before the point at which tahoe-lafs/tahoe-lafs was 
>> originally forked from it? I don't know.

Nope, forking is a github thing, not a git thing: there's no record in
the git history of anything involving repository forks. So we can change
it with relative impunity. However it's a useful signal to newcomers to
have the most-official repo be the parent of the visible github forking
tree.

So yeah, we should all re-fork our repos from the official
tahoe-lafs/tahoe-lafs one.

I suspect that deleting a repo cause all of its fork-children to be
re-fork-parented to the deleted repo's fork-parent. I don't know what
happens when you delete the root of the fork-tree: maybe everyone
becomes a root, maybe everyone becomes a child of some randomly-selected
repo.

When I set up tahoe-lafs/tahoe-lafs, I think I could have done something
differently to automatically move everything over (some sort of
transfer-ownership thing). But I didn't, and I don't think I can do
anything simple now that both my repo and the official one have
fork-children.

So we should either:

* get everyone who's forked from me to delete their repos and re-fork
  from the official one, then once my repo has no fork-children, I can
  do the same.

or

* submit a github support request to have them jiggle the database and
  accomplish the same thing without doing a bunch of shady and/or risky
  deletes

I'll do the latter when I get a round tuit.

>> It's not strictly necessary for other repos to re-fork. The
>> advantage of doing so is that they'll get updates from trunk
>> faster, because they won't have to wait for Brian to pull from
>> trunk to his repo. But not re-forking does not create any
>> impediment to integrating patches from those repos.
> 
> I think that's true.  reforking does mean pull requests go to the
> right place.

Forking doesn't affect anything about the git repo you get when you
clone your new fork. That local repo's "origin" remote points at your
own fork, and nothing (unless you manually add something later) points
at the fork-parent.

But yes, pull requests will target the fork-parent by default, and we'd
like all pull-requests to be aimed at the official repo, so all
committers can respond to (and close) them, not just me.

cheers,
 -Brian