How would you find an appropriate commit? -------------------------- Regards, Marlene Cote Affirmed Networks 978-268-0821 ->-----Original Message----- ->From: Jens.Lehmann@xxxxxx [mailto:Jens.Lehmann@xxxxxx] ->Sent: Friday, July 15, 2011 3:28 PM ->To: Marlene Cote ->Cc: git@xxxxxxxxxxxxxxx ->Subject: Re: [PATCH] git-submodule: Remove duplicate entries during merge with conflict -> ->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