Thanks. I've decided to use a single instance of the main framework (Bones), downloaded as a zip, and created a new repo and added the files myself, then added the other framework, Inuit, as a submodule, which seems to work well for my purposes.
Jason - - - [image: Jason Bradberry's Logo] Website Design | Graphic Design | Branding w. http://jasonbradberry.com t. http://twitter.com/@jasonbradberry On 8 June 2013 22:33, Thomas Ferris Nicolaisen <tfn...@gmail.com> wrote: > On Friday, June 7, 2013 10:29:25 PM UTC+2, jasonbr...@gmail.com wrote: > >> I'm new to git, and having done a fair bit of reading up I've set up a >> github account ready to get started. >> >> I plan to combine elements of Inuit CSS (https://github.com/** >> csswizardry/inuit.css <https://github.com/csswizardry/inuit.css>) with >> Bones >> (https://github.com/**eddiemachado/bones<https://github.com/eddiemachado/bones>) >> to create my own starter framework for Wordpress projects. >> >> My question is should I fork each of these projects and clone them >> locally, then edit/combine and upload to a new repository? The help info >> regarding forking appears to imply that you would fork a repository when >> you were looking to contribute to the original repository rather than >> create a derivative work, or perhaps that is just the most common use case? >> >> The other option I can see is to just download the repository for each as >> a zip file, combine/edit and then upload them to a new repository. >> >> Is there a benefit to either route or perhaps another approach that I >> might be missing? >> > > There aren't any big disadvantages of basing a derivative on a fork. The > advantage is that you have history (i.e. documentation) for all the code. > If they have a lot of history with changes to larger binary files (images), > you may want to cut that out (using the BFG repo cleaner or something) to > trim down the size of the repo. > > The only thing that may bother you is that the GitHub page will say that > this repo is a fork of [origin], but that is just a GitHub feature that I > believe you can by-pass by simply cloning the origin repo to your local > disk, and then pushing it to a freshly created empty repo on GitHub. > > I would clone them both to your local disk, add them as remotes to your > project's repository, fetch and merge in. If you want them both to appear > as subfolders, you can use the subtree merge strategy. If you are not going > to modify them, and you'll continuously be updating them with updates from > the original repositories, you may want to consider using git subtree, or > git submodules to include the sources. > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Git for human beings" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/git-users/A4EPrkENU3I/unsubscribe?hl=en-US > . > To unsubscribe from this group and all its topics, send an email to > git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
