I have a quick question on whether this is a good workflow for keeping various projects with OF
I have projects running back to version 0.6.2 of OF, I had kept each version of OF that I was using so the projects would still compile and I did not have to update them (lazy/busy). With this I was duplicating a lot of addons and OF versions and it was taking up too much space.
I though I could make my life simpler and put everything together and switch tags if I needed to get to an older version fast.
This seems to work quite well but in my effort to keep organised and keep my folder structure my OF folder now looks like this:
The subfolders of_0.6.2 etc contain the apps and app subfolders from previous versions of OF.
Is there any reason this is not a good idea (it freed up a lot of needed space for me).
If it is OK, is there a reason it would be bad to change the git ignore file for OF to allow these folders to be ignored (or rather to allow only the files that are in the original repo?
that’s totally ok, perhaps what we could do is add a gitignore rule for /apps* so if you name your folders apps_007 or anything similar they’ll also get ignored wihtou having to modify the original gitignore. modifying it is mostly ok but you could accidentalyy commit it while sending a pull request or similar
Yes, great, it would be much better if the real git ignore was altered.
can you open a pull request with this change?
I love this approach of organizing OF folder! I’ve been trying to do it similar way lately to keep OF contained within just one folder. But I have a lot of problem organizing version of addons used in each apps also. Which is much more troublesome since most of the time I have no clue which fork I’m using (the older the worse my memories get) and most of the time they aren’t tagged with compatible version numbers.
Guess that’s a more complicated problem to solve…
really wish we could have something like
package.json in npm to organize this in OF
@firmread I have a little addon manager gulpfile, which I am planning to port to oF. It clones addons to a local directory and checkout the specified version.
See this post: Suggestions for an ofAddonManager
It should not be too hard to program this on oF. I guess all we need is ofxJson and libgit2.
@thomasgeissl I would love to see gulpfile version that you have! Is it on github somewhere?
Zach’s discussion on pg repo that mentioned in the original post was quite a rabbit hole for me to read up, lol. But I think that raised an interesting use case that I don’t think is very common for web development (?) and I’m wondering if your tool to find specific commit would cover it. I, too, sometimes have a need to modify the addon just to make it fit with each project’s use case and save it locally, which is not necessary an important fix that will ever get to go through pull request on the original repo.
Well, it could be just simply about ability to managing multiple remote for the addon I guess.
It will be tomorrow on github.
since 0.9.0 you can use this: How do you use git for versioning an oF project? to have copies of the addons in each project. you can combine it with git submodules so each project points to a specific commit too