How do you use git for versioning an oF project?


#1

I’ve been banging my head on this question for a little bit, and I’d be curious to hear how people deal with versionining a oF project with git. (I’m new with git and may be missing something obvious)

To give some context, here’s an idea of my current oF setup:

  • apps/myProjectA/app1
  • apps/myProjectA/app2
  • apps/anotherUnreleatedProjectB/…
  • addons/addon_I_always_use
  • addons/addon_I_customized_for_projectA
  • addons/addon_for_projectB

So basically I have my “goto” oF disitribution with a bunch of projects in it, I want to version on git one specific project and at least the addons I’ve modified for it. What would you do in this situation ? My personal ideas:

  • Create a new fork/copy of oF and git the whole stuff

  • Pro: self contained

  • Con: code duplication, especially for addons I may re-use elsewhere, makes a giant git repo

  • Create lots of repository for all the individual component

  • Pro: clean for the project file

  • Con: get a bit messy for addons shared accross multiple repo (but they can have more than one “origin” address), gets complicated to make sure all the dependencies are up to date ? ( I guess there are also dependencies manager, but yuk)

  • Look like submodules could also help resolving dependencies

  • Create only one repo for my addons and app that lives within my oF distribution, and manually select the files I want to export

  • Pro: easy to pull all the dependencies at once

  • Con: will become quite a mess if I do that for multiple project

  • Hardlinks my addons at /apps/myProject/addons/… and git that

  • Not sure how well that would work…

Well in advance, thanks for those who share their opinion about that, and I’ll reply/edit this post to tell you about the solution I went for.

ps. For more context, I’m on windows, using atlassian’s stash and visual studio. But ideally this post will serve beyond my own case…


#2

in 0.9.0 we added local addons that allow you to have addons in your project from any path. it’s supported yet by the PG gui but you can use addons.make to add them and then run the PG to update the project or use the command line PG.

i’ve been using them by having an addons folder in the top level folder of the project, instead of the app like:

OF
  |_apps
    |_project
      |_addons
        |_ofxTween
      |_someapp
      |_someotherapp

then addons.make should look like:

ofxGui
../addons/ofxTween

where ofxGui will be used from the root addons folder and ofxTween from the local one.

you can also use submodules with this if you want and allows to have everything in one repo without cloning all of OF


Branches and my of folder
#3

@arturo I didn’t read about this new feature on the changes post, I probably missed it but its a great approach.

@silverbahamut We did in the past a combined version of your approach, basically having two origins (one being ofx github and one being our repository). We updated ofx time to time form ofx origine, and keep our code in our repository. While this work, it creates a giant repo difficult to maintain, and keep track of addons changes is really time consuming.

The process that arturo describes make perfect sense to maintain the project integrity (even you can use submodules for that)


#4

In addition to using submodules for addons as Arturo mentions, you can also make OF itself a submodule. This is nice since you can easily keep OF at a certain tag (like 0.9.0), or a specific commit (i.e. if you need something post-0.9.0 that hasn’t made it into a release yet), or if you fork OF into your own account and make some project-specific commits. When cloning your project, git clone --recursive https://project.url/repo.git will get all addons & OF at the proper commits which is very handy.

The biggest downside is here you’re making another copy of OF for your project, which takes a while to download the multi-GB repo and takes as much disk space. Not the right solution for every situation, but a nice option to have…


#5

i haven’t tried, but --depth 1 should reduce download time and disk space considerably. not sure if clone --recursive passes the depth parameter to all submodules as well.


#6

In case anybody comes across this topic (like I did) with more questions about exactly how use “local” addons in projects, there is a useful explanation at https://github.com/openframeworks/openFrameworks/issues/5932


Cannot compile a local addon