Reputation: 164
I wrote some scripts that compute large amounts of data and return some statistical values which I used for an assignment of mine which was due a few months ago.
Now I'd like to collaborate on an extension of this project with a few people. My understanding was that I should create a fork of that project. I do not think it's suitable to create an extra organisation for this as the team is temporary and only works on this single project, at least for now.
As explained in How do you fork your own repository on GitHub? and Can/should I fork my own github repo? you cannot create a fork of your own repository on GitHub. I tried to use the suggested workaround of cloning and pushing to a new repo, which works fairly well. I don't really bother that I can't PR across the projects, but the issue with this approach for me is that all commits are double counted as activity on my profile.
I contacted GitHub support on this and asked whether they could either attach the project as a fork (private forks of your own repo seem to be allowed in some cases anyway, cp. Collaborating in a temporary private fork to resolve a security vulnerability) or to remove the commits in one of those repository from my contribution activity. They apparently are not able to do so. Their suggestion was to use a custom email adress e.g. [email protected]
which is not linked to my GitHub account. Although this would work I'd have to rewrite history to do so and the commit SHAs in both repositories wouldn't match afterwards, which I do not really like.
My other solutions would either be to just completely scrap the history in the new project and squash all previous commits into one that references the old repository or to work on a branch instead of a fork, like mentioned here: How can I fork my own GitHub repository?.
The charm of a new repo would be that both projects would have their corresponding names, by squashing the commits and adding a reference to the base project I'd make it clear that the project is not brand new/ from scratch and I would not have the hassle to get confused by different SHAs in what would be basically the same commit with different email adresses in my repo. On the other hand I'd drastically cut down the commit count of this repo which also doesn't feel quite right.
If I'd go the branching route, should I rather create an <old project name>
-branch at the current state and continue to work on master
or should I leave master
as it is and create a <new project name>-master
branch? Also how would I go about the name of the repository? Leave it as is or give it a new name? Remember: I'd like to have the state of the first project to be preserved in a way I can easily access it later. Would this be more of a job for a tag or an inactive branch?
Please note that I'm not really asking for opinions. Much rather interpret this question as: What would be the benefits and drawbacks (additional to those mentioned above) of what I would call a "pseudo-fork" compared to the branching solution?
In case of the "pseudo-fork"-route: What are the benefits and drawbacks of a no-contribution
mail vs. the squashing of commits?
In case of the branching route: How should I name the branches, what are the associated pros and cons of the approaches that I might have missed? What are the benefits of renaming the repo vs. keeping the old name (linking is not an issue, as both repos are still private)? In case of a rename, would it be a good idea to reference the "old" branch or tag in the README.md
that is on the repository home page, or would this lead to problems?
Upvotes: 1
Views: 662
Reputation: 164
I've decided to go with two repositories, where one is a pseudo fork of the other (i.e. clone, change remote, push) and changed the author and committer of those old commits.
Upvotes: 1