I noticed some of the initial imports of projects into Git still maintain the SVN trunk/tags/branches structure. I read a couple articles today that deal with converting those to Git style branches and tags.
Migrating From SVN to Git Preserving Branches And Tags (http://www.sailmaker.co.uk/blog/2013/05/05/migrating-from-svn-to-git-preserving-branches-and-tags-3/)
Convert Git-SVN Tag Branches to Real Tags (http://gitready.com/advanced/2009/02/16/convert-git-svn-tag-branches-to-real-tags.html)
It comes down to using extra flags during the git svn init, and then possibly some post conversion of git remote branches into tags. I tried it out using the NetFixServer project. This was possible even though the project has been deleted from the head revision in SVN, since git-svn will search through history and find it in previous revisions. Using the --stdlayout flag removes the extra SVN folder structure, and converts the contents into the expected Git branches:
mkdir NetFixServer
cd NetFixServer
git svn init https://svn.outpostuniverse.org:8443/svn/outpost2/NetFixServer/ --stdlayout
git svn fetch
Alternatively, the "--stdlayout" flag can be replaced and expanded into "-t tags -b branches -T trunk". This lets you adjust for any naming differences to the standard layout (case sensitive).
There was also the bit about converting the remote branches to proper Git tags. I modified one of the examples from the above links to the following:
git for-each-ref refs/remotes/origin/tags | cut -d / -f 5- | while read ref;
do git tag -a "$ref" -m"say farewell to SVN" "refs/remotes/origin/tags/$ref"
done
I suspect we can probably tag a bit better, but that's a start. The folder structure is much cleaner this way. What I don't like about the tagging is the extra commit message. It looks a bit like a double commit, once from the SVN tagging, and once from the Git tagging. Perhaps the original revision can be tagged directly with the SVN tag message.
These are the commands that I used for it:
git svn clone URL_HERE
git filter-branch -f --tree-filter "rm -fr TestFiles" --prune-empty HEAD
git remote add origin URL_TO_GITHUB_PROJECT
git remote -v
git push origin master
Though it seems like yours are more about converting the 'standard layout' of SVN repositories into a regular layout for Git.
Vagabond was asking about putting OP2MapImager up onto GitHub. I thought I'd document the process.
The OP2MapImager project did not have the standard SVN trunk/tags/branches folder structure, so no special conversion was needed there. OP2MapImager had the standard format OP2 tilesets as part of the project. Since these were proprietary, they needed to be filtered out. This removes the files not just from the HEAD revision, but also from all previous commits, ensuring there is no trace left in the repository. The project also previously had some maps for test data. The test data was removed by a previous commit, but the map files still existed in history. Again, since they were proprietary, they needed to be filtered out. The project also contained 7za.exe and the FreeImage library. Checking the licensing files, it appears they both allow for redistribution, and so they were left in with no changes.
The conversion steps were:
mkdir OP2MapImager
cd OP2MapImager/
git svn init https://svn.outpostuniverse.org:8443/svn/outpost2/GameResources/OP2MapImager/
git svn fetch
git filter-branch --tree-filter "rm -f OP2MapImager/*.bmp" --prune-empty HEAD
git filter-branch -f --tree-filter "rm -rf OP2MapImager/TestFiles/" --prune-empty HEAD
To upload the results to GitHub, a GitHub repository needs to be created first. This can be done from the GitHub website. To resulting URL was: https://github.com/OutpostUniverse/OP2MapImager.git
To upload the contents of the local repository to the new empty GitHub repository:
git remote add origin https://github.com/OutpostUniverse/OP2MapImager.git
git push -u origin master
The project is now up on GitHub. The URL for the page is:
https://github.com/OutpostUniverse/OP2MapImager
(https://github.com/OutpostUniverse/OP2MapImager)
I spent a bit more time this weekend looking into repository conversions.
GitHub has instructions on Splitting a Subfolder Out Into a New Repository (https://help.github.com/articles/splitting-a-subfolder-out-into-a-new-repository/). This could be used on a full SVN -> Git repository conversion to split it into individual projects. The main tool is the filter-branch command with the --subdirectory-filter option:
git filter-branch --prune-empty --subdirectory-filter FOLDER-NAME BRANCH-NAME
Another point of interest, is the git-svn command can combine the git svn init and git svn fetch commands into a single git svn clone command.
I also tried experimenting with breaking the --stdlayout flag into the individual -b (--branches), -t (--tags), and -T (--trunk) flags:
git svn clone -b branches/API/Outpost2DLL/ -t tags/API/Outpost2DLL/ -T trunk/API/Outpost2DLL/ https://svn.outpostuniverse.org:8443/svn/outpost2/LevelsAndMods/ Outpost2DLL
There is a tagged release of the SDK that I wanted to preserve. There was also a branch I wanted to preserve, though realized much later the branch was only for the OP2Helper project, and not for Outpost2DLL. Because of this confusion, my expectations were off, and so I wasn't seeing the results I expected. This lead to a lot of extra reading, and experimenting with various flags, such as the ones shown above.
Ok, I think I found a way of getting rid of a lot of the ugliness with a project that has been moved multiple times in the original SVN repo. The ugliness being quite a few revisions in the imported history with silly trivial changes, such as files being moved in and out of "trunk", "tag", and "branch" folders. This is an artifact of how SVN stores branches and tags, rather than real project changes. If you move a project folder within the repository layout, you're changing the repository layout, not the project. As such, this noise is not really desirable, as it doesn't reflect any changes to the project, and so should be filtered out along with other external changes, such as modifications to other projects.
It seems it's possible to filter out these changes by specifying multiple trunk, tag, and branch options when doing the conversion. You just have to know the history of where the project has existed in the source repo, and specify each location.
To get the history of project locations, I cheated a bit, and used a full SVN -> Git repo conversion that contains all projects. I then searched and filtered through all paths over all commits to get a quick list of where the project of interest was over time. For the OP2Helper project this could be one by searching for the main header file:
git log --pretty=format: --name-only --diff-filter=A | sort -u | grep OP2Helper.h
This produced the following list of files, from which paths could be extracted and classified:
API/HFL/SDKInclude/OP2Helper.h
API/OP2Helper/branches/BaseBuilderV2/OP2Helper.h
API/OP2Helper.h
API/OP2Helper/OP2Helper.h
API/OP2Helper (tag - SDK-V2)/OP2Helper.h
API/OP2Helper/tags/OP2Helper - SDK-V2/OP2Helper.h
API/OP2Helper/tags/OP2Helper (tag - SDK-V2)/OP2Helper.h
API/OP2Helper/trunk/OP2Helper.h
LevelsAndMods/API/OP2Helper/branches/BaseBuilderV2/OP2Helper.h
LevelsAndMods/API/OP2Helper/tags/OP2Helper - SDK-V2/OP2Helper.h
LevelsAndMods/API/OP2Helper/trunk/OP2Helper.h
LevelsAndMods/branches/BaseBuilderV2/OP2Helper/OP2Helper.h
LevelsAndMods/tags/SDK-V2/OP2Helper/OP2Helper.h
LevelsAndMods/trunk/API/OP2Helper/branches/BaseBuilderV2/OP2Helper.h
LevelsAndMods/trunk/API/OP2Helper/OP2Helper.h
LevelsAndMods/trunk/API/OP2Helper/tags/OP2Helper - SDK-V2/OP2Helper.h
LevelsAndMods/trunk/API/OP2Helper/trunk/OP2Helper.h
ZZJ-misc/Include/OP2Helper.h
Then to import the history:
git svn clone -b LevelsAndMods/trunk/API/OP2Helper/branches/ -b LevelsAndMods/branches/*/OP2Helper/ -b LevelsAndMods/API/OP2Helper/branches/ -b API/OP2Helper/branches/ -t LevelsAndMods/trunk/API/OP2Helper/tags -t LevelsAndMods/tags/*/OP2Helper/ -t LevelsAndMods/API/OP2Helper/tags/ -t API/OP2Helper/tags/ -T LevelsAndMods/trunk/API/OP2Helper/ -T LevelsAndMods/API/OP2Helper/trunk/ -T API/OP2Helper/trunk/ https://svn.outpostuniverse.org:8443/svn/outpost2/ OP2Helper
Checking the history of the resulting project repository:
git log --pretty=format: --name-only --diff-filter=A | sort -u
And the history comes out quite clean. No trunk, tag, or branch folders:
BaseBuilder.cpp
BaseBuilder.h
BaseBuilderV2.h
EnumSoundID.h
EnumTechID.h
Lib/OP2Helper.lib
OP2Helper.cpp
OP2Helper.dsp
OP2Helper.dsw
OP2Helper.h
I did a bit more tweaking to the OP2Helper project before uploading it.
I filtered out the OP2Helper.lib file, which should never have been added to source control in the first place. This project is a static library, so the lib file is the output, much like a DLL or EXE is the output of other projects.
git filter-branch --index-filter 'git rm --cached --ignore-unmatch -r Lib' --prune-empty --tag-name-filter cat -- --all
Note the Outpost2DLL project does contain a lib file, but that is used as an input to link to Outpost2.exe. The Outpost2DLL.lib file would essentially be an output when compiling Outpost2.exe, which we don't have source code for. This lib file had to be generated through other means, from the Outpost2 executable file itself. Hence why the Outpost2DLL contains a .lib file in the repository, but other projects don't.
I searched history to find possibly missed traces of .lib files, perhaps outside of the Lib folder. To get a fairly raw dump of what the repository is holding, I found rev-list to be useful:
git rev-list --objects --all
I also came across a way to get a list of the 10 largest files in the repository. A good way to know if somewhere in history you've accidentally committed something big, which is eating up a lot of repository space. First run git gc to generate pack files. Then combine rev-list with verify-pack. This outputs a list of hashes and file names:
git gc
git rev-list --objects --all | grep "$(git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -10 | awk '{print$1}')"
I found a command that lists hashes, file sizes, and file names, all sorted by size. It's a bit more complicated, but the output is very nice:
git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | awk '/^blob/ {print substr($0,6)}' | sort --numeric-sort --key=2 | cut --complement --characters=13-40 | numfmt --field=2 --to=iec-i --suffix=B --padding=7 --round=nearest
I took a look at the tags. It seems two branches were created for the SDK-V2 tag. In Subversion, tags are actually full branches, and you can commit to them, though it warns you not to. Nevertheless, someone did indeed commit to the SDK-V2 branch, which is why the tag showed up twice during the conversion.
I tagged the original branch point as "v2.0.0". I tagged the most recent SVN version as "v2.1.0". For the commit that was erroneously added on top of the tag branch in SVN, I tracked back to it's proper branch point, created a new branch, cherry-picked the changes over to the new branch as the first commit. I then updated the code to make the style a bit more consistent with the rest of the SDK as a second commit. The changes were then merged it in to master branch as a merge commit.
During all this, I found my editor was trying to make changes to unexpected lines. Eventually I figured out it was cleaning up sloppy whitespace. Things like spaces and tabs at the end of lines. Rather than blend the changes in with the rest of the merge, or fight it indefinitely, I opted to cleanup the whitespace for the whole project in an additional commit.
I also investigated the BaseBuilderV2 branch. I found the code had all been committed, seemingly by accident, in various out of order stages at later dates, to trunk in SVN. Hence the branch contained no additional code. After verifying it really was all already on master, I chose to just discard the branch.
Well, that was a long convoluted learning process. The OP2Helper conversion is finally up on GitHub though.
Now that I know much more about what I'm doing, I think I might want to revisit the Outpost2DLL project. I encountered some of the same problems there, with the noisy history from the project being moved around during SVN repository layout updates. It might be worth redoing that conversion before people start using it.
Ok, Outpost2DLL has been converted, fixed, and pushed up to GitHub. Everything seems to be right this time. Check it out.
We should discuss tagging at some point. I tagged the initial commit as "v2.0.0", which corresponds with the SDK-V2 release. I was thinking of also tagging the last commit from SVN. Not sure how appropriate that is, and if it should be tagged as "v2.1.0" or "v3.0.0". Assuming we go with semantic version numbers anyway. Maybe we should stick to something simpler. Also, the SDK was previously packaged as a set of projects, with one version number for all of them. Now, the projects will exist independently in Git, so we might consider separate version numbers.
There's also the Git distinction between simple tags and annotated tags. That's an issue I'd like to delay a bit on for now. I used a simple tag, but perhaps I'll switch it to an annotated tag at some point. I saw one piece of advice that suggests simple tags are more appropriate for local use, while annotated tags are more appropriate for shares use in the master repository.
As for the conversion. As I added more and more options to git-svn clone, I found it did less and less of what I wanted it to do. Eventually I gave up on trying to get git-svn clone to do the full conversion in one step, and just used a simpler clone command to get a basic messy conversion done, and then cleaned it up a bit with a few filter commands to rewrite history and remove the odd Subversion artifacts.
The result contains the root of the project as the root of the repository, with no spurious trunk or tag folders floating around in history. The history contains all changes to the project, and I triple checked SVN revision numbers on this one. Every commit contains changes to project code. There are no empty commits. There are also no commits with changes external to the project, such as the project as a whole being moved around within the SVN repository, nor other projects being copied into the project folder or otherwise having files side-by-side in the same folder. There were points in history where the same folder was used by multiple projects.
One difference between Git and SVN, is Git only tracks files, not folders. Existence of folders is implied by paths of stored files. If an SVN commit only adds an empty folder, that commit will appear empty after being imported into Git. Similarly, if you move all the files out of a folder, the folder will disappear in Git. There was a bit of that going on throughout history, such as adding a placeholder folder in one commit, then moving files in a second commit. In particular, the first commit did this, though wasn't automatically pruned by the other commands.
The conversion worked something like this:
# Initial SVN -> Git import
git svn clone \
-T LevelsAndMods/trunk/API/Outpost2DLL/ \
-t LevelsAndMods/trunk/API/Outpost2DLL/tags/ \
https://svn.outpostuniverse.org:8443/svn/outpost2/ Outpost2DLL
cd Outpost2DLL
# Remove empty commits
git filter-branch --prune-empty master
# Remove any "tags" folders
git filter-branch --index-filter 'git rm -rf --cached --ignore-unmatch tags/' --prune-empty -f -- --all
# Move any files in "trunk" folders back to root
git filter-branch --tree-filter 'test -d trunk/ && mv trunk/* ./ || echo "Nothing to do"' --prune-empty -f -- --all
# Remove the empty initial commit
git rebase -i --root
# Tag the initial commit, which was the SDK-V2 release
git tag v2.0.0 `git rev-list --max-parents=0 HEAD`
# Push changes up to GitHub
git remote add origin https://github.com/OutpostUniverse/Outpost2DLL.git
git push origin v2.0.0
Ok, the fixed OP2Helper conversion has been re-uploaded to GitHub. Check it out.
A Pull Request was created for some code that had been erroneously committed to a tag (which in SVN are actual branches). It's use is a bit dated, but still good. It can be auto merged in. I figure I'll leave someone else to review it and make a decision to include in master or not.
The conversion:
# Initial conversion from SVN to Git
git svn clone \
-T LevelsAndMods/trunk/API/OP2Helper/ \
-t LevelsAndMods/tags/*/OP2Helper/ \
-b LevelsAndMods/branches/*/OP2Helper \
https://svn.outpostuniverse.org:8443/svn/outpost2/ OP2Helper
cd OP2Helper
# Remove the initial blank commit
git rebase -i --root
# Move spurious copies in trunk back to project root
git filter-branch --tree-filter 'test -d trunk/ && mv trunk/* ./ || echo "Nothing to do"' --prune-empty -f -- --all
# Remove spurious tag subfolders
git filter-branch --index-filter 'git rm --cached --ignore-unmatch -r tags' --prune-empty --tag-name-filter cat -f -- --all
# Remove spurious branches subfolders
git filter-branch --index-filter 'git rm --cached --ignore-unmatch -r branches' --prune-empty --tag-name-filter cat -f -- --all
# Remove erroneously committed copies of the compiled lib file
git filter-branch --index-filter 'git rm --cached --ignore-unmatch -r Lib' --prune-empty --tag-name-filter cat -f -- --all
# Tag the initial commit
git tag v2.0.0 `git rev-list --max-parents=0 HEAD`
A few updates were made to master to fix minor issues. Branch updates for a lost commit to a tag were brought over from a previous conversion attempt.
# Branch for ZZJ's commit, based on tagged release
git checkout -b centerView v2.0.0
# Bring in changes from previous conversion attempt
git fetch ../OP2Helper-old/ master
# Cherry pick changes (ZZJ's commit, and updates to code style)
git cherry-pick FETCH_HEAD~3^2^
git cherry-pick FETCH_HEAD~3^2
# Handle merge conflict
git merge master
After that, the results were uploaded to GitHub, and a Pull Request was created.
git remote add origin https://github.com/OutpostUniverse/OP2Helper.git
git push -u origin master
git push -u origin centerView
git push origin v2.0.0
HFL seems like a sensible next project to convert.
HFL and HFL-IUnit projects have been converted and uploaded to GitHub.
Conversion steps:
git svn clone -T LevelsAndMods/trunk/API/HFL/ https://svn.outpostuniverse.org:8443/svn/outpost2/ HFL
git svn clone -T LevelsAndMods/trunk/API/HFL-IUnit/ https://svn.outpostuniverse.org:8443/svn/outpost2/ HFL-IUnit
Both projects had history filtered to remove empty commits, and .lib files.
For HFL:
git rebase -i --root
git filter-branch --index-filter 'git rm --cached --ignore-unmatch -r Lib' --prune-empty --tag-name-filter cat -f -- --all
For HFL-IUnit:
git rebase -i --root
git filter-branch --index-filter 'git rm --cached --ignore-unmatch -r op2extra.lib' --prune-empty --tag-name-filter cat -f -- --all
After that, projects were uploaded to GitHub.
For HFL:
git remote add origin https://github.com/OutpostUniverse/HFL.git
git push -u origin master
For HFL-IUnit:
git remote add origin https://github.com/OutpostUniverse/HFL-IUnit.git
git push -u origin master
Ahh, thanks. Seems I had a git-svn branch checked out from a point before that project was added, and didn't see it. (The branch was the point before the modification to Outpost2.exe that messed up the OllyDbg comment tracking).
I see the files now with:
svn log https://svn.outpostuniverse.org:8443/svn/outpost2/LevelsAndMods/trunk/API/Outpost2Dialog -v
I'm not sure either way about combining the projects. op2ext depends on Outpost2DLL but doesn't need any code from OP2Helper. Reducing the number of projects could be a good thing though.
I think that was my original reasoning for the current project organization. I really wanted to keep things separate. Don't add dependencies you're not using, and don't mix our additions with original Outpost 2 interface stuff. Though what I was thinking now, is separate folders within one project. Perhaps something like:
Outpost2DLL\
game\ (Formerly Outpost2DLL)
shell\ (Formerly Outpost2App)
opu\ (Formerly OP2Helper)
In terms of compiled size, the linker will strip out anything that's not used, so combining projects should not affect final output.
There are some usability concerns this would address. The project settings adjustments needed to add a new API project can be confusing for new people. After all, there is a wiki article on this topic. ;) By combining it into one standard project, which a standard template comes preconfigured to use, they have exactly what they need, without worrying about configuration, and without having to select the right template to get all the dependent projects they need.
Such a change means we'd have a proper static library project, rather that a pseudo header-file-only static library project. Either which way, you still need to link a .lib file, since these all depend on the .lib for Outpost2.exe. It was never a true header-only project to begin with.
I converted the projects in LevelTemplates from the SVN repo and put them up on GitHub. These projects contain relative references to the API projects. We should convert them to use Git submodules. Once that is done, we can look into updating instructions to use the GitHub template projects to build new levels.
Projects converted:
LevelTemplate-Blank
LevelTemplate-Blank-WithComments
LevelTemplate-Hooville
During the conversion, I experimented with the Hub command line tool to create projects on GitHub without using the GitHub web interface. It seems Hub still defaults to use SSH rather than HTTPS. There are plans to change the default to HTTPS. Meanwhile, to keep things consistent, Hub can be configured to use HTTPS with:
git config --global hub.protocol https
An example conversion looks something like this:
git svn clone https://svn.outpostuniverse.org:8443/svn/outpost2/ -T LevelsAndMods/trunk/LevelTemplates/Hooville Hooville
cd Hooville
git rebase -i --root
git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | awk '/^blob/ {print substr($0,6)}' | sort --numeric-sort --key=2 | cut --complement --characters=13-40 | numfmt --field=2 --to=iec-i --suffix=B --padding=7 --round=nearest
git filter-branch --index-filter 'git rm --cached --ignore-unmatch -r trunk/' --prune-empty --tag-name-filter cat -- --all
git log --oneline --name-status
git filter-branch --index-filter 'git rm --cached --ignore-unmatch -r tags/' --prune-empty --tag-name-filter cat -f -- --all
# Create project on GitHub
hub create -d "Hooville multiplayer template mission" OutpostUniverse/LevelTemplate-Hooville
# This should push up to GitHub, though a failed previous attempt may have set SSH protocol
#git push origin master
# To fix the SSH -> HTTPS settings I used
git remote remove origin
git remote add origin https://github.com/OutpostUniverse/LevelTemplate-Hooville.git
git push -u origin master
I went back to revisit the NetFixServer and NetFixClient projects. They had been imported early and still had the messy trunk and tag folders. They also hadn't yet been touched or added to on GitHub, so I went ahead and redid the imports for those projects to clean them up a bit.
For NetFixServer, I'd already tested and did a proper import ages ago, but had never got around to uploading and overwriting the existing repo. I think at the time I was still a little uncertain of what I was doing with Git and GitHub. To upload the more recently converted repo, the steps were:
git remote add origin https://github.com/OutpostUniverse/NetFixServer.git
git push -u origin master -f
git push origin v1.0.0
I already had a checked out version of the old repo, which other people might too. To update things on the client side after a forced push, I used:
git fetch
git reset origin/master
git checkout .
git clean -f
The clean didn't seem to remove old folders, so I manually deleted those.
For the NetFixClient import, the steps were:
# Initial import
mkdir NetFixClient
cd NetFixClient
git svn init https://svn.outpostuniverse.org:8443/svn/outpost2/NetFix/Client/ --stdlayout
git svn fetch
# Checked repo for stray "trunk" or "tag" folders (courtesy of StackOverflow)
git rev-list --objects --all | git cat-file --batch-check='%(objecttype) %(objectname) %(objectsize) %(rest)' | awk '/^blob/ {print substr($0,6)}' | sort --numeric-sort --key=2 | cut --complement --characters=13-40 | numfmt --field=2 --to=iec-i --suffix=B --padding=7 --round=nearest
# Checked for empty commits to filter out (there were none)
git rev-list --count HEAD # 26
git rebase -i --root
git rev-list --count HEAD # 26
git filter-branch --index-filter 'git rm --cached --ignore-unmatch -r trunk/' --prune-empty --tag-name-filter cat -- --all
git rev-list --count HEAD # 26
# Clean up an old empty commit message
git rebase -i --root
# => Used "reword" on the offending message, and added a description of the change
# View branches to see SVN tags
git branch -a -v
# Convert SVN branches into Git tags
# Note: The commit message change above rewrote history.
# This step required matching up previous commits with new commit IDs by examining log messages
git tag -a 2011-11-18 15c6001
git tag -a 2008-09-27 a7e00a6
# Pushing changes up to GitHub
git remote add origin https://github.com/OutpostUniverse/NetFixClient.git
git push -u origin master -f
git push origin 2008-09-27 2011-11-18
I looked into the steps needed to convert the ForcedExports project from SVN to Git. During the conversion, I'm planning to rename it to OP2Internal.
As the SVN server is currently down, I've been testing the steps using a local backup. This means references and comments in my experiment point to a local copy, rather than the official one. I'm planning to either re-run the steps from the official repository, or perhaps find a way to rename the references.
Conversion steps (though my initial clone command used a modified source):
# Initial clone (and folder rename)
git svn clone https://svn.outpostuniverse.org:8443/svn/outpost2/ -T LevelsAndMods/trunk/API/ForcedExports OP2Internal
# Move spurious copies in trunk back to project root
git filter-branch --tree-filter 'test -d trunk/ && mv trunk/* ./ || echo "Nothing to do"' --prune-empty -f -- --all
# Remove accidentally committed .obj file
git filter-branch --index-filter 'git rm --cached --ignore-unmatch -r Build/' --prune-empty --tag-name-filter cat -f --
# Reword commit messages...
git rebase -i --root
Side note: I'm really glad I created this thread, as this stuff gets really hard to remember after a while.
The old "ForcedExports" project has been uploaded to GitHub as "OP2Internal".
After re-running the above steps from the now up and running SVN repository, the final upload commands were:
git remote add origin https://github.com/OutpostUniverse/OP2Internal.git
git push -u origin master
Hopefully this unblocks some needed NetFix development.