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

During a merge with conflict on a submodule, the submodule appears 3 times in git ls-files (stage 1,2,3) which causes the submodule to be used 3 times in git submodule update or status command.
This patch filters the results of git ls-files and only shows submodule in stage 0 or 1 thus removing the duplicates.

Signed-off-by: Nicolas Morey-Chaisemartin <redacted>
---
 git-submodule.sh |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index 3a13397..5ef0f9d 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh

@@ -72,7 +72,7 @@ resolve_relative_url ()
 #
 module_list()
 {
-	git ls-files --error-unmatch --stage -- "$@" | sane_grep '^160000 '
+	git ls-files --error-unmatch --stage -- "$@" | sane_grep '^160000 ' | awk '{ if (($3 == 0) || ($3 == 1)) print $0}'
 }
 
 #

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?  
If I have to choose my version or their version, that isn't really a merge,
or is it?
Thanks.

--
View this message in context: http://git.661346.n2.nabble.com/PATCH-git-submodule-Remove-duplicate-entries-during-merge-with-conflict-tp6180061p6584432.html
Sent from the git mailing list archive at Nabble.com.

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.

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.

Am 15.07.2011 22:32, schrieb Marlene Cote:

How would you find an appropriate commit?

The same way you resolve conflicts for a regular file: If you are unlucky
and the merge strategy doesn't resolve the conflict for you automatically
(or at least gives you a hint what /could/ be the resolution), you have
to use human judgment to find an appropriate resolution. In most cases
that will be a commit where both conflicting commits show up in the
history (and maybe you'll even have to create one yourself by doing a
proper merge in the submodule).

Where I work we have a simple best practice that guarantees us git will
always find a proper resolution itself: We only record commits that are
on the submodules master branch in the superproject. To put it in other
words: merge the submodule first before you commit in the superproject.