Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
How to manage an oil generated app with GIT
  • I think this is more of a GIT question. When I generate an app with oil it pulls different projects from GIT it seems. If I want to manage this app in my own git repo how would I go about doing that?
  • It depends a bit what you want, because there are a lot of options. The only repository that is relevant for you is fuel/fuel, as this is where your application will like. All others are git submodules, and I would leave them like that so you can easily update them if needed. For fuel/fuel, what I usually do is add a second remote which points to my app repository, and make that the default. So push and pulls normally operate from there. But because the original remote (the fuel repo) is still there, it's easy to merge in changes if need be.
  • I was migrating an existing application to use Fuel, so I set up the Git submodule mappings manually instead of using Oil. First create a regular Git repository for your app and then do something like:
    git submodule add git://github.com/fuel/core.git fuel/core
    git submodule add git://github.com/fuel/oil.git fuel/packages/oil
    git submodule init
    git submodule update
    
  • Thanks for the replies. I haven't been using git for to long so the submodule concept was new to me. I read up on it and seem to get it now. My app deployment process consists of me running git on a deployment server to pull the latest changes and then updating the app and running database migrations as needed. I'm assuming I just need to add the git submodule update command to my existing "git pull" process for updating the deployment server with the latest code to ensure I do in fact have all the changes in the project. Does that seem correct? I currently have a one-size fits all deployment process; would running "git submodule update" on projects without submodules bomb anything out or cause any issues that you know of in the git repo itself (of course my code will break :)?
  • There are a lot of pitfalls when using submodules, so read carefully before you decide to use them. One major pain is that a submodule can not point to a branches HEAD, it always points to a commit hash. So it you have your app (which is either a clone of fuel/fuel with the remote changed to your server) or an install in your own repo, adding a submodule will create a link to a specific commit. A 'submodule update' will always update up to that commit, so in fact nothing will ever change as long as you don't change that commit hash. What you have to do:
    - go into each of your submodule folders
    - do a git checkout <branchname> to switch to the desired branch
    - do a git pull to update that branch if you now do a 'git status' in you app, you'll see the submodules be in a modified state, marked with 'new commits'. If you now commit all changes in your app, the submodule commit hash will have been modified to reflect the changes the pull has made. If you now do a 'submodule update' on your deployment server, the submodules will be updated to the new commit hash. This mechanism allows you to modify the code in the branch (which could make the branch unstable) without impacting code that relies on that branch (because it is linked to a known and stable commit hash). Once you've switched the local repo's to the correct branch, you can do 'git submodule git pull' to pull them all at once. If you do that from a clean app, a 'git commit -a -m "update references" will then update your submodule commit hash references.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion