If you cloned fuel/fuel locally, it contains submodules for the other repositories. Submodules are pointers to a specific commit hash in an other repository.
If you update that other respository, or switch branches, git sees that the latest commit hash has changed, so it reports the submodule as modified.
If you commit the fuel/core change, the submodule reference in your project will be updated, and will be from then on linked to the commit hash that identifies 1.6/develop (at the stage you updated).
You will have to do the same for all package repositories as well, so everything points to 1.6.
and that restored the core files, but then when I:
cd ../..
git status
it's telling me that fuel/core has new commits. I don't want to commit from the staging server. It's just supposed to pull from the bare repo. On my local machine, the fuel/core repo had to be "merged" with my existing fuel/core repo. I'm not sure why this is, as I have not made any changes in fuel/core in the history of this project. Do I need to rebase fuel/core or something?
Should update the submodules just fine. This is how we update the submodule references in the fuel/fuel repository all the time.
Is that the only message or is that followed by an "unable to checkout 4a9aae2712de2b9ca0978aedefe6e15e4b3a4acb" ?
I don't know what you did locally, but 4a9aae2712de2b9ca0978aedefe6e15e4b3a4acb is not a valid commit hash in our fuel/core repository. So I can only assume you changed something locally, and commited that change as the submodule reference.
Merge branch '1.6/develop' of git://github.com/fuel/core into 1.6/develop
When I did the git pull in fuel/core it treated it as a merge. I'm not sure why, but I'm guessing it's because back when I switched from 1.4/master to 1.6/develop, there was a merge conflict that I had to resolve manually. Once again, I'm not sure why. Do I need to remove the submodule and re-add it, or is there some other way I can scrap the 4a9aae commit? The previous commit is the most recent from 1.6/develop.
Donate
