# git submodule status during merge

1 messages from 2011-03-16 to 2011-03-16. Participants: Nicolas Morey-Chaisemartin.
Thread: https://gitlist.dev/t/26747

## Nicolas Morey-Chaisemartin, 2011-03-16 09:32

Subject: git submodule status during merge
Message-ID: <4D8083C9.4070300@morey-chaisemartin.com>
URL: https://gitlist.dev/e/4D8083C9.4070300%40morey-chaisemartin.com

```
Hi,

While I was trying to merge a superproject with tons of submodule (conflicting) I noticed that several submodules show 3 times when running "git submodule status"

Ex:
+c31377d713fa3ef03960de6672ce69d2a1e7317e gdb (reverse-20080717-branchpoint-7820-gc31377d)
+c31377d713fa3ef03960de6672ce69d2a1e7317e gdb (reverse-20080717-branchpoint-7820-gc31377d)
+c31377d713fa3ef03960de6672ce69d2a1e7317e gdb (reverse-20080717-branchpoint-7820-gc31377d)

After a quick investigation, it appears this is due to module_list in git-submodule which uses
        git ls-files --error-unmatch --stage -- "$@" | sane_grep '^160000 '
to retrieve a list of all available submodules.

As there is a conflict, the submodules show in 3 different stages.
The status command later uses
    cd "$path" && git rev-parse --verify HEAD
so the same SHA1 is displayed for the 3 times the submodule appears.

Although it is not a big issue, it is quite puzzling for most people.
So here are the few questions:
    * Is this an expected behaviour and if yes, why?
    * If not, is module_list the place to fix it?
It does not seem that any of the git commands are using the stage information yet. So I suppose keeping only one of the entries should not be too problematic.
Simply filtering with something like awk '{ if ($3 == 0 || $3 == 1) print $0}'  seems to solve the problem

Thanks in advance

Nicolas Morey-Chaisemartin

```