threads / discuss / 26747

git submodule status during merge

Subject: git submodule status during merge

## tl;dr

One message between Mar 16, 2011 and Mar 16, 2011.

replies: 0people: 1as markdown or json

Nicolas Morey-Chaisemartin· Mar 16, 2011, 09:32 UTC · lore
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

← back to recent threads