Am 14.07.2011 20:33, schrieb funeeldy: > How can new users of git submodules learn about merge conflicts? When and > why they occur, and how to resolve them in a way that doesn't lose commits? That is pretty similar to merge conflicts in regular files: They happen when you merge two branches where both sides changed the recorded submodule commit to another one (and those are not the same). The resolution can be done by finding a submodule commit that has both changes. In most cases that will be based on a merge (maybe even a fast forward) with both commits in its history. If git finds a fast forward from the merge base to commit1 and commit2 (let's say they both are on master and newer than the merge base), the newer one is picked automatically. If git finds a single merge from which both commits are reachable, it proposes that as conflict resolution and tells you how you can stage that. Only if it doesn't find any or more than two merges, you are on your own and have to resolve the conflict manually by finding an appropriate commit. > If I have to choose my version or their version, that isn't really a merge, > or is it? It would be if the merge strategy is "ours" or "theirs". But in most normal cases you would want to have both commits reachable from the merge result. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html