Re: [PATCH] submodule: Alllow staged changes for get_superproject_working_tree

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 28, 2018, 18:00 UTC
Message-ID: <xmqqftxtcxjb.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <37DC7525-209F-49CC-90AA-D55463456D20@gmail.com>

Sam McKelvie <sammck@gmail.com> 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.