git submodule status during merge
- From
Nicolas Morey-Chaisemartin <devel-git@morey-chaisemartin.com>
- Date
- Mar 16, 2011, 09:32 UTC
- Message-ID
- <4D8083C9.4070300@morey-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 problemThanks in advance
Nicolas Morey-Chaisemartin