views:

546

answers:

2

I'm having difficulty merging from my master branch to a separate branch I've been developing on in quite sometime.

Doing a straight forward merge I get the following:

shell$ git merge master
fatal: cannot read object asd211f3a58febecd4e447szxs733079211c71b7sa '/my/sub/dir/foo~master': It is a submodule!

I never setup the library 'foo' as a submodule explicitly. I made the mistake of moving a library that itself was versioned by git with a .git subdirectory into the main project, that is also a git repository.

Apparently I didn't remove the submodule properly, or something else is seriously broken.

The more pressing issue, is that after the failed merge, I see a staggering amount of project files via 'git status'. There are files 'that have been changed, but not added' in addition to 'Untracked files'. These are not files from my branch, they are files from master.

I'm not even sure how many different levels of broken that is. But this is a two step problem. The submodule in addition to a bunch of files after the failed merge showing up.

What's the best way to clean this repository up?

+1  A: 

May I suggest:

git reset --hard ORIG_HEAD

Then investigate the submodule with:

git submodule status

Do you have a .gitmodules file in place? Do your best to remove the notion of a submodule from both branches (commit that), and then re-attempt your merge.

gahooa
Tried that, get the following:shell$ git reset --hard ORIG_HEADHEAD is now at f6ed2d5 Fooshell$ git submodule statusshell$ git checkout mastererror: Untracked working tree file '/path/to/some/dir/foo.png' would be overwritten by merge.shell$
Coocoo4Cocoa
Also, I see no sign of a .gitmodules file, anywhere. (In either of the branches)
Coocoo4Cocoa
A: 

In my case, I have a branch called "main" that depends on a specific version of a library, stored and tracked as a submodule. The master (trunk) uses the dev version of the library, and thus has the submodule removed. Doing a simple git merge would fail when it got to the submodule and provide no clues for what to do next:

 git merge --no-commit main/urology-main
 fatal: cannot read object 7bd71249fc9575b7985bcd6b65e77f14690a6be6 'Utech_DTools': It is a submodule!

Google turned up this similar question where it was suggested to use a specific "resolve" merge strategy:

 git merge -s resolve --no-commit main/urology-main
 ERROR: Utech_DTools: Not handling case 66001ac8d03d8b930c72536d3946ca40e3810320 ->  -> 7bd71249fc9575b7985bcd6b65e77f14690a6be6

However, the merge did continue after skipping the submodule.

David Dombrowsky