Hacker News Reader

Comment by pilif | Hacker News Reader

I don't know. Personally, I love submodules. Once you "get it", it's really straight forward.

It really shines, if you use them for third party libraries that you are keeping patches for. In the old days, updating said libraries was nearly impossible once you began patching them. With submodules, you can use git's really cool merging capabilities to help you.

Even better: The workflow when updating a library patched by you to a newer upstream version stays the same as if you'd just do a traditional merge in your own codebase. So there's no need to learn even more commands or new workflows - it just works.

I'm a huge, huge fan of how git submodules work.

View on HN

Until you have merge conflict. If someone could explain to me which file contains the conflict markers so I can fix them I'd be really happy. Its not the .gitmodules file.

if it's a merge conflict happening while updating the submodule, then the conflict is inside the working copy of that submodule. Go there and resolve it using the usual tools, commit and commit the updated submodule revision in the parent repository

Except that doesnt work, because that just changes the hash of the submodule (as stored by the supermodule) again. The problem is that the supermodule just stores the hash of the submodule. The only way I found of fixing it was to:

1. Create a new repo.

2. Get the branched submodule.

3. Check that in as head: Note, now HEAD will NOT compile - I've committed broken code.

4. Go back to the original repo.

5. Get HEAD: this pulls the hash I need.

6. Do the merge. The submodule doesn merge, because it has the right hash.

Surely there must be some way to just modify the hash. But I don't know where to change it. I found it in several locations, but I don't know how it works, and hacking my VCS isnt my idea of good sense.

the command you are looking for is git diff. git status will show you which files changed, git diff will show you where the conflicts are in the files during the merge.

I am pretty certain in this situation that git diff claims that the submodule directory itself has somehow been modified from the previous commit hash to the new one. Please recognize that the case here is a merge conflict between two people advancing the commit the submodule points to to different revisions of the subproject, not merge conflicts inside of the subproject (which really should not be happening).

Reply on news.ycombinator.com