GoKit
GoKit copied to clipboard
prime31
What do you think about rearranging this repo so it could be a submodule or a subtree?
I have my projects set up where I clone different repos, with different components or functionality, into the main repo via git submodule functionality. The GoKit repo, being an entire Unity project, is not suited to doing that. Sparse-Checkout also results in a rather messy directory structure because it must create all directories from root. What do you think of the idea of making this repo, and potentially others, organized into a structure that allows someone to git submodule add, or git subtree add them into their project directly?
I personally like the idea but to be completely honest most Unity users can't manage a Git submodule if their life depended on it. What I usually do is just pull the repo in a separate folder and then symlink the GoKit folder. It's not perfect since you have to set it up on each computer to be in the same location but it does work now that Unity fixed the symlink issue.
Mike
On Mar 20, 2015, at 6:49 PM, Ryan Goodrich [email protected] wrote:
I have my projects set up where I clone different repos, with different components or functionality, into via git submodule functionality. This repo, being an entire Unity project, is not suited to doing that. Sparse-Checkout also results in a rather messy directory structure because it must create all directories from root. What do you think of the idea of making this repo, and potentially others, organized into a structure that allows someone to git submodule add, or git subtree add them into their project directly?
— Reply to this email directly or view it on GitHub.
+1
I've always been confused by this project's layout. The problem with putting the project in a different folder and symlinking is that the repo root is usually the Unity project folder, so that would duplicate everything. Placing it outside of the repo obviously fails because it is not under version control. Also I don't think Windows supports symlinking, so it's not a complete solution for Unity.
Also adding *.meta to .gitignore would be appropriate, since Unity generates those for you.
Also adding *.meta to .gitignore would be appropriate, since Unity generates those for you.
Nooooo! Meta files definitely need to be committed. Allowing Unity to regenerate them can end up with new GUIDs and all kinds of craziness.
The Unity package manager is becoming to defacto way to handle adding 3rd party code to projects. Adding UPM support is fairly easy and I'm happy to show you how I've done it for my project: https://github.com/IxxyXR/Polyhydra-upm
@andybak bwahahah. Yes, I can't even remember being under the misconception now. I've made a couple of upm packages too coincidentally, definitely the move for any open source Unity package.