Am 21.03.2011 09:43, schrieb Nicolas Morey-Chaisemartin: > I agree that the actual behavior of status is definitely wrong and it should be changed. Yup. > But I think there needs to be a simple way for a user to know whats happening to a conflicted submodule. > When merging a file, editing the conflicting area in the code is often enough. > For a submodule, I think the user needs an easy access to which branch used what SHA1. You can see the sha1s using "git diff": diff --cc submod index bd4cfe7,7128fbd..0000000 --- a/submod +++ b/submod (But the sha1s don't tell you much about what differing commits you have in the submodule branches, which would be really helpful for deciding how to solve the merge conflict. Unfortunately "git diff --submodule" doesn't work for merge conflicts yet, another issue on my ToDo-list ...) > Git submodule status is probably not the right place to do that. I agree. > git ls-files --stage allows that but it's not part of the standard porcelain commands... And it shows you three sha1s, one of them being the current state of the submodule. Me thinks the output of "git diff" is easier to digest. > I'll check/test the patch you proposed as soon as possible and repost it if it's allright ! Cool! -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html