> On Sep 28, 2018, at 11:00 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Sam McKelvie <sammck@xxxxxxxxx> writes: > >>> Ah, that, too. I meant to correct triple ell, though ;-) >>> ... >> >> I wholeheartedly approve of that plan and your tweaking commit below. Thank you, Junio. > > Thanks for a fix. But now I re-read the title and think about it, > this is mistitled. The word 'stage' in "ls-files --stage" is not > about 'stage' people use when they talk about "staged changes" at > all. The latter is what "diff --cached" is about---what's different > between HEAD and the index. The 'stage' "ls-files --stage" talks > about is "which parent the cache entry came from, among common > ancestor, us, or the other branch being merged". > > Also we are not really "allowing" with this change; "allowing" makes > it sound as if we were earlier "forbidding" with a good reason and > the change is lifting the limitation. > > We used to incorrectly die when superproject is resolving a conflict > for the submodule we are currently in, and that is what the patch > fixed. > > submodule: parse output of conflicted ls-files in superproject correctly > > is the shortest I could come up with, while touching all the points > that need to be touched and still being technically not-incorrect. > > Or perhaps > > rev-parse: --show-superproject-working-tree should work during a merge > > may be more to the point. It does not hint the root cause of the > bug like the other one, but is more direct how the breakage would > have been observed by the end users. > Haha, that is closer to my original title that Stefan wanted to change: submodule.c: Make get_superproject_working_tree() work when superproject has unmerged changes of the submodule reference Though I could see why mine was too long. I’m really happy with both your suggestions. If you still think you can squash it with your own tweaks, great. Let me know If you’d prefer another patch.
