On 03/17/2011 09:50 PM, Junio C Hamano wrote: > Junio C Hamano <gitster@xxxxxxxxx> writes: > >> Nicolas Morey-Chaisemartin <devel-git@xxxxxxxxxxxxxxxxxxxxxx> writes: >> >>> 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. >> That is a wrong thing to do. What if both sides added a submodule at the >> same directory after forked from an ancestor that did not have it? You >> will have only stage #2 and stage #3, no? After a quick check, you're right on that ;) > It is not very friendly to say a solution is wrong without hinting what > the right thing to do, so let's try. Thanks for taking the time to point me in the right direction ! > There are 5 callers of module_list; they all read (mode, sha1, stage, > path) tuple, and most of them care only about path. As a first level > approximation, it should be Ok (in the sense that it does not make things > worse than it currently is) to filter the duplicate paths from module_list > output. > ... > - Status does not have anything to report for an unmerged submodule. It > may want to recurse into the submodule of the unmerged one, but people > involved in submodule work should think things through; and > I agree that the actual behavior of status is definitely wrong and it should be changed. 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. Git submodule status is probably not the right place to do that. git ls-files --stage allows that but it's not part of the standard porcelain commands... I guess a first step should be to apply the patch you proposed and discuss a later solution to get the submodule SHA1 (well except if there's already one I just don't know about !) I'll check/test the patch you proposed as soon as possible and repost it if it's allright ! Nicolas Morey-Chaisemartin -- 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