RE: [PATCH] git-submodule: Remove duplicate entries during merge with conflict

How would you find an appropriate commit?

-------------------------- Regards, Marlene Cote Affirmed Networks 978-268-0821

->-----Original Message----- ->From: Jens.Lehmann@web.de [mailto:Jens.Lehmann@web.de] ->Sent: Friday, July 15, 2011 3:28 PM ->To: Marlene Cote ->Cc: git@vger.kernel.org ->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.