1

I have a really weird, bad scenario here. Disclaimer, I'm new to git, and I've kind of screwed up.

SO I have lots of submodules in my fork, based on monodevelop.

First: I couldn't even update my submodules using git submodule update --init --recursive.
I tried bunch of similar commands, with rebase, foreach, etc. So I finally got the latest using git submodule foreach git pull origin master. After this I got all my files. I then committed and pushed my changes

Now: I just noticed that all my submodules have conflicts. <<<<<<< HEAD, etc. I have no idea where these came from, and I don't know how to fix these.

git status says everything is up-to-date. submodule update says everything is up to date, even with force. git fetch says everything is up-to-date.

harsimranb
  • 2,231
  • 1
  • 35
  • 55

2 Answers2

1

git submodule update --init --recursive would update your submodules to a specific SHA1, recorded in the index of your main repo (as a gitlink entry).

If you need for a submodule to follow a branch, you can convert that submodule declaration in order to make it follow that branch with (after the init step) a git submodule update --recursive --remote.
See "Git submodules: Specify a branch/tag"

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1

For anyone who messes up their submodules. I also got some help from my friend on this.

What I had done was merge the submodules and commit them into my master. General rule of thumb is I shouldn't do that, and instead make separate pull request to the submodule repo with the changes.

Anyways, I just went into each submodule directory, git log # hit q to cancel out of the entire output.. When I got the commit sha for the right commit I want to go back to.
Then I did git reset --hard c5652 # Partial commit id, if no other branch or file have that name. This is the fix for my issue.

I'm not crystal clear on the whole workings, and I'll definitely be reading more.

harsimranb
  • 2,231
  • 1
  • 35
  • 55
  • putting a submodule content into master is indeed not good: it removes the gitlink entry I mention in my answer and replaces it with a regular folder. The `reset --hard` is a good move. +1 – VonC Jun 11 '14 at 15:20
  • @VonC Yes, that's where i screwed up. I wasn't aware that it would mess up the gitlink. It was out of ignorance, I should've paid better attention to what was getting committed. I'm glad its resolved now. :) – harsimranb Jun 11 '14 at 16:17