Re: Diffs for submodule conflicts during rebase usually empty
- From
Jens Lehmann <jens.lehmann@web.de>
- Date
- Sep 13, 2014, 11:07 UTC
- Message-ID
- <54142577.3080104@web.de>
- In-Reply-To
- <1410526589-sup-2306@sabre>
Am 12.09.2014 um 15:03 schrieb Edward Z. Yang:
Show 23 quoted lines
> 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.