Subject: Re: Diffs for submodule conflicts during rebase usually empty

From: Jens Lehmann <[email-masked]>
Date: Sat, 13 Sep 2014 13:07:35 +0200

Am 12.09.2014 um 15:03 schrieb Edward Z. Yang:
> Hello Jens,
>
> Excerpts from Jens Lehmann's message of 2014-09-11 15:29:28 -0400:
>> Git does know what's going on, just fails to display it properly
>> in the diff, as the output of ls-files shows:
>>
>>      $git ls-files -u
>>      160000 6a6e215138b7f343fba67ba1b6ffc152019c6085 1    b
>>      160000 fc12d3455b120916ec508c3ccd04f23957c08ea5 2    b
>>      160000 33d9fa9f9e25de2a85f84993d8f6c752f84c769a 3    b
>
> Right. But I'd also add that even though Git knows what's going
> on, even if we reported /that/ it wouldn't be user friendly:
> namely, because submodules are not updated automatically so the
> first line would always be what the submodule was pointed to
> before we started rebasing.  That's not so useful either...
>
>> I agree that this needs to be improved, but am currently lacking
>> the time to do it myself. But I believe this will get important
>> rather soonish when we recursively update submodules too ...
>
> As I've said, I'm happy to contribute a patch, if we can agree
> what the right resolution is...

Me thinks the next step would be that "git diff --submodule"
should learn to not only show 2-way diffs but also 3-way diffs.
Then we'll be able to display submodule merge results in a human
readable way. After that we would have to find a way to display
submodule merge conflicts in a human readable way, similar to
what we do with conflict markers for regular files.