views:

42

answers:

1

Hi there, i use the git workflow as described in this blogpost. In short: everybody develops inside his/her own branch, before merging back to master, you rebase your branch to master again to get clean history.

This works.

Now we have a submodule, and because this is an in-house plugin (Rails), we need to change this often. So most of the times i have changes both in the general branch and in the submodule branch.

What is the best way to work with submodules in the workflow as above.

I first try to push my changes to the submodule (git checkout master, git pull, git checkout branch, git rebase master, git checkout master, git merge branch).

Then, when i try to do the same for my root, i always get an error on my plugin (submodule). I have to resolve the error, before doing git rebase --continue. So if try to git mergetool i converts my folder to a file.

After the rebase has ended, i just restore the <folder_name>.orig to overwrite the file <folder_name> and all is well.

But somehow it feels there should be a better way.

In short: when working via checkout-b/rebase/merge - workflow, how do you handle the changed submodules simultaneously?

+2  A: 

Whatever workflow you are following with submodules, there is one rule you shouldn't forget:
(From the Git tutorial)

If you want to make a change within a submodule, you should first check out a branch, make your changes, publish the change within the submodule, and then update the superproject to reference the new commit.

$ git checkout master
$ echo "adding a line again" >> a.txt
$ git commit -a -m "Updated the submodule from within the superproject."
$ git push
$ cd ..
$ git add a        # There is a gotcha here.  Read about it below.
$ git commit -m "Updated submodule a."

So did you commit the new state of your submodule within the parent project before attempting your rebase/merge from said parent project?

VonC