[PATCH] submodule: Alllow staged changes for get_superproject_working_tree

[PATCH] submodule: Alllow staged changes for get_superproject_working_tree

[Sam McKelvie]

Invoking 'git rev-parse --show-superproject-working-tree' exits with

    "fatal: BUG: returned path string doesn't match cwd?"

when the superproject has an unmerged entry for the current submodule,
instead of displaying the superproject's working tree.

The problem is due to the fact that when a merge of the submodule reference
is in progress, "git ls-files --stage —full-name <submodule-relative-path>”
returns three seperate entries for the submodule (one for each stage) rather
than a single entry; e.g.,

$ git ls-files --stage --full-name submodule-child-test
160000 dbbd2766fa330fa741ea59bb38689fcc2d283ac5 1       submodule-child-test
160000 f174d1dbfe863a59692c3bdae730a36f2a788c51 2       submodule-child-test
160000 e6178f3a58b958543952e12824aa2106d560f21d 3       submodule-child-test

The code in get_superproject_working_tree() expected exactly one entry to
be returned; this patch makes it use the first entry if multiple entries
are returned.

Test t1500-rev-parse is extended to cover this case.

Signed-off-by: Sam McKelvie <sammck@gmail.com>
---
 submodule.c          |  2 +-
 t/t1500-rev-parse.sh | 17 ++++++++++++++++-
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/submodule.c b/submodule.c
index 33de6ee5f..5b9d5ad7e 100644
--- a/submodule.c
+++ b/submodule.c
@@ -1885,7 +1885,7 @@ const char *get_superproject_working_tree(void)
 		 * We're only interested in the name after the tab.
 		 */
 		super_sub = strchr(sb.buf, '\t') + 1;
-		super_sub_len = sb.buf + sb.len - super_sub - 1;
+		super_sub_len = strlen(super_sub);
 
 		if (super_sub_len > cwd_len ||
 		    strcmp(&cwd[cwd_len - super_sub_len], super_sub))
diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh
index 5c715fe2c..b774cafc5 100755
--- a/t/t1500-rev-parse.sh
+++ b/t/t1500-rev-parse.sh
@@ -134,7 +134,6 @@ test_expect_success 'rev-parse --is-shallow-repository in non-shallow repo' '
 test_expect_success 'showing the superproject correctly' '
 	git rev-parse --show-superproject-working-tree >out &&
 	test_must_be_empty out &&
-
 	test_create_repo super &&
 	test_commit -C super test_commit &&
 	test_create_repo sub &&
@@ -142,6 +141,22 @@ test_expect_success 'showing the superproject correctly' '
 	git -C super submodule add ../sub dir/sub &&
 	echo $(pwd)/super >expect  &&
 	git -C super/dir/sub rev-parse --show-superproject-working-tree >out &&
+	test_cmp expect out &&
+	test_commit -C super submodule_add &&
+	git -C super checkout -b branch1 &&
+	git -C super/dir/sub checkout -b branch1 &&
+	test_commit -C super/dir/sub branch1_commit &&
+	git -C super add dir/sub &&
+	test_commit -C super branch1_commit &&
+	git -C super checkout master &&
+	git -C super checkout -b branch2 &&
+	git -C super/dir/sub checkout master &&
+	git -C super/dir/sub checkout -b branch2 &&
+	test_commit -C super/dir/sub branch2_commit &&
+	git -C super add dir/sub &&
+	test_commit -C super branch2_commit &&
+	test_must_fail git -C super merge branch1 &&
+	git -C super/dir/sub rev-parse --show-superproject-working-tree >out &&
 	test_cmp expect out
 '
 
-- 
2.17.1

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

[Stefan Beller]

On Thu, Sep 27, 2018 at 11:12 AM Sam McKelvie <sammck@gmail.com> wrote:
>
> Invoking 'git rev-parse --show-superproject-working-tree' exits with
>
>     "fatal: BUG: returned path string doesn't match cwd?"
>
> when the superproject has an unmerged entry for the current submodule,
> instead of displaying the superproject's working tree.
>
> The problem is due to the fact that when a merge of the submodule reference
> is in progress, "git ls-files --stage —full-name <submodule-relative-path>”
> returns three seperate entries for the submodule (one for each stage) rather
> than a single entry; e.g.,
>
> $ git ls-files --stage --full-name submodule-child-test
> 160000 dbbd2766fa330fa741ea59bb38689fcc2d283ac5 1       submodule-child-test
> 160000 f174d1dbfe863a59692c3bdae730a36f2a788c51 2       submodule-child-test
> 160000 e6178f3a58b958543952e12824aa2106d560f21d 3       submodule-child-test
>
> The code in get_superproject_working_tree() expected exactly one entry to
> be returned; this patch makes it use the first entry if multiple entries
> are returned.
>
> Test t1500-rev-parse is extended to cover this case.
>
> Signed-off-by: Sam McKelvie <sammck@gmail.com>

Thanks for following up, this patch is
Reviewed-by: Stefan Beller <sbeller@google.com>

Thanks for adding the test as well!
Stefan

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

[Junio C Hamano]

Sam McKelvie <sammck@gmail.com> writes:

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

s/Alllow/allow/;

> Invoking 'git rev-parse --show-superproject-working-tree' exits with
>
>     "fatal: BUG: returned path string doesn't match cwd?"
>
> when the superproject has an unmerged entry for the current submodule,
> instead of displaying the superproject's working tree.
>
> The problem is due to the fact that when a merge of the submodule reference
> is in progress, "git ls-files --stage —full-name <submodule-relative-path>”
> returns three seperate entries for the submodule (one for each stage) rather
> than a single entry; e.g.,
>
> $ git ls-files --stage --full-name submodule-child-test
> 160000 dbbd2766fa330fa741ea59bb38689fcc2d283ac5 1       submodule-child-test
> 160000 f174d1dbfe863a59692c3bdae730a36f2a788c51 2       submodule-child-test
> 160000 e6178f3a58b958543952e12824aa2106d560f21d 3       submodule-child-test
>
> The code in get_superproject_working_tree() expected exactly one entry to
> be returned; this patch makes it use the first entry if multiple entries
> are returned.
>
> Test t1500-rev-parse is extended to cover this case.
>
> Signed-off-by: Sam McKelvie <sammck@gmail.com>
> ---
>  submodule.c          |  2 +-
>  t/t1500-rev-parse.sh | 17 ++++++++++++++++-
>  2 files changed, 17 insertions(+), 2 deletions(-)
>
> diff --git a/submodule.c b/submodule.c
> index 33de6ee5f..5b9d5ad7e 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -1885,7 +1885,7 @@ const char *get_superproject_working_tree(void)
>  		 * We're only interested in the name after the tab.
>  		 */
>  		super_sub = strchr(sb.buf, '\t') + 1;
> -		super_sub_len = sb.buf + sb.len - super_sub - 1;
> +		super_sub_len = strlen(super_sub);

As we are reading from "ls-files -z -s", we know that the name is
terminated with NUL, so we can just use strlen().  Good.
>  
>  		if (super_sub_len > cwd_len ||
>  		    strcmp(&cwd[cwd_len - super_sub_len], super_sub))
> diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh
> index 5c715fe2c..b774cafc5 100755
> --- a/t/t1500-rev-parse.sh
> +++ b/t/t1500-rev-parse.sh
> @@ -134,7 +134,6 @@ test_expect_success 'rev-parse --is-shallow-repository in non-shallow repo' '
>  test_expect_success 'showing the superproject correctly' '
>  	git rev-parse --show-superproject-working-tree >out &&
>  	test_must_be_empty out &&
> -

I have a feeling that this break made the series of tests in this
block easier to follow.  Shouldn't we be moving in the other
direction, namely ...

>  	test_create_repo super &&
>  	test_commit -C super test_commit &&
>  	test_create_repo sub &&
> @@ -142,6 +141,22 @@ test_expect_success 'showing the superproject correctly' '
>  	git -C super submodule add ../sub dir/sub &&
>  	echo $(pwd)/super >expect  &&
>  	git -C super/dir/sub rev-parse --show-superproject-working-tree >out &&
> +	test_cmp expect out &&

Here is an end of one subtest, deserves to have a break like the above.

> +	test_commit -C super submodule_add &&
> +	git -C super checkout -b branch1 &&
> +	git -C super/dir/sub checkout -b branch1 &&
> +	test_commit -C super/dir/sub branch1_commit &&
> +	git -C super add dir/sub &&
> +	test_commit -C super branch1_commit &&
> +	git -C super checkout master &&
> +	git -C super checkout -b branch2 &&
> +	git -C super/dir/sub checkout master &&
> +	git -C super/dir/sub checkout -b branch2 &&
> +	test_commit -C super/dir/sub branch2_commit &&
> +	git -C super add dir/sub &&
> +	test_commit -C super branch2_commit &&
> +	test_must_fail git -C super merge branch1 &&

and all of the above is just a set-up for another subtest, so a
solid block of text like we see in the above is good.

	Side note: there are a few of

		git -C $there checkout $onebranch &&
		git -C $there checkout -b $anotherbranch &&

	as recurring pattern.  Shouldn't they be more like a single
	liner

		git -C $there checkout -b $anotherbranch $onebranch &&

	?  It wasn't clear if the split was an attempt to hide some
	breakage (e.g. "checkout -b B A" did not work but "checkout
	A && checkout -b B" did) or just being verbose because the
	author is not used to "checkout -b B A" form.

> +	git -C super/dir/sub rev-parse --show-superproject-working-tree >out &&
>  	test_cmp expect out
>  '

Thanks.

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

[Sam McKelvie]

All of your comments seem reasonable; however, since the patch was signed off by Stefan it
Is unclear to me whether I should submit another patch or what. I apologize for not being
facile with the patching workflow.

> On Sep 27, 2018, at 3:02 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Sam McKelvie <sammck@gmail.com> writes:
> 
>> Subject: Re: [PATCH] submodule: Alllow staged changes for get_superproject_working_tree
> 
> s/Alllow/allow/;
> 

Ok, no caps on first letter of subject.

>> Invoking 'git rev-parse --show-superproject-working-tree' exits with
>> 
>>    "fatal: BUG: returned path string doesn't match cwd?"
>> 
>> when the superproject has an unmerged entry for the current submodule,
>> instead of displaying the superproject's working tree.
>> 
>> The problem is due to the fact that when a merge of the submodule reference
>> is in progress, "git ls-files --stage —full-name <submodule-relative-path>”
>> returns three seperate entries for the submodule (one for each stage) rather
>> than a single entry; e.g.,
>> 
>> $ git ls-files --stage --full-name submodule-child-test
>> 160000 dbbd2766fa330fa741ea59bb38689fcc2d283ac5 1       submodule-child-test
>> 160000 f174d1dbfe863a59692c3bdae730a36f2a788c51 2       submodule-child-test
>> 160000 e6178f3a58b958543952e12824aa2106d560f21d 3       submodule-child-test
>> 
>> The code in get_superproject_working_tree() expected exactly one entry to
>> be returned; this patch makes it use the first entry if multiple entries
>> are returned.
>> 
>> Test t1500-rev-parse is extended to cover this case.
>> 
>> Signed-off-by: Sam McKelvie <sammck@gmail.com>
>> ---
>> submodule.c          |  2 +-
>> t/t1500-rev-parse.sh | 17 ++++++++++++++++-
>> 2 files changed, 17 insertions(+), 2 deletions(-)
>> 
>> diff --git a/submodule.c b/submodule.c
>> index 33de6ee5f..5b9d5ad7e 100644
>> --- a/submodule.c
>> +++ b/submodule.c
>> @@ -1885,7 +1885,7 @@ const char *get_superproject_working_tree(void)
>> 		 * We're only interested in the name after the tab.
>> 		 */
>> 		super_sub = strchr(sb.buf, '\t') + 1;
>> -		super_sub_len = sb.buf + sb.len - super_sub - 1;
>> +		super_sub_len = strlen(super_sub);
> 
> As we are reading from "ls-files -z -s", we know that the name is
> terminated with NUL, so we can just use strlen().  Good.
>> 
>> 		if (super_sub_len > cwd_len ||
>> 		    strcmp(&cwd[cwd_len - super_sub_len], super_sub))
>> diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh
>> index 5c715fe2c..b774cafc5 100755
>> --- a/t/t1500-rev-parse.sh
>> +++ b/t/t1500-rev-parse.sh
>> @@ -134,7 +134,6 @@ test_expect_success 'rev-parse --is-shallow-repository in non-shallow repo' '
>> test_expect_success 'showing the superproject correctly' '
>> 	git rev-parse --show-superproject-working-tree >out &&
>> 	test_must_be_empty out &&
>> -
> 
> I have a feeling that this break made the series of tests in this
> block easier to follow.  Shouldn't we be moving in the other
> direction, namely …
> 
That’s fair.


>> 	test_create_repo super &&
>> 	test_commit -C super test_commit &&
>> 	test_create_repo sub &&
>> @@ -142,6 +141,22 @@ test_expect_success 'showing the superproject correctly' '
>> 	git -C super submodule add ../sub dir/sub &&
>> 	echo $(pwd)/super >expect  &&
>> 	git -C super/dir/sub rev-parse --show-superproject-working-tree >out &&
>> +	test_cmp expect out &&
> 
> Here is an end of one subtest, deserves to have a break like the above.

OK

> 
>> +	test_commit -C super submodule_add &&
>> +	git -C super checkout -b branch1 &&
>> +	git -C super/dir/sub checkout -b branch1 &&
>> +	test_commit -C super/dir/sub branch1_commit &&
>> +	git -C super add dir/sub &&
>> +	test_commit -C super branch1_commit &&
>> +	git -C super checkout master &&
>> +	git -C super checkout -b branch2 &&
>> +	git -C super/dir/sub checkout master &&
>> +	git -C super/dir/sub checkout -b branch2 &&
>> +	test_commit -C super/dir/sub branch2_commit &&
>> +	git -C super add dir/sub &&
>> +	test_commit -C super branch2_commit &&
>> +	test_must_fail git -C super merge branch1 &&
> 
> and all of the above is just a set-up for another subtest, so a
> solid block of text like we see in the above is good.
> 
> 	Side note: there are a few of
> 
> 		git -C $there checkout $onebranch &&
> 		git -C $there checkout -b $anotherbranch &&
> 
> 	as recurring pattern.  Shouldn't they be more like a single
> 	liner
> 
> 		git -C $there checkout -b $anotherbranch $onebranch &&
> 
> 	?  It wasn't clear if the split was an attempt to hide some
> 	breakage (e.g. "checkout -b B A" did not work but "checkout
> 	A && checkout -b B" did) or just being verbose because the
> 	author is not used to "checkout -b B A" form.

You’re right, the two forms are equivalent and the single-line version is simpler.

> 
>> +	git -C super/dir/sub rev-parse --show-superproject-working-tree >out &&
>> 	test_cmp expect out
>> '
> 
> Thanks.

Thank you.

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

[Junio C Hamano]

Sam McKelvie <sammck@gmail.com> writes:

>>> Subject: Re: [PATCH] submodule: Alllow staged changes for get_superproject_working_tree
>> 
>> s/Alllow/allow/;
>> 
>
> Ok, no caps on first letter of subject.

Ah, that, too.  I meant to correct triple ell, though ;-)

When one reviewer says Reviewed-by: but you later found that the
patch was not good enough to deserve a redoing, feel free to redo
the patch and do not add the Reviewed-by: you got for the old one
to your second submission.  The difference between the one that was
reviewed and the one you updated invalidates the stale Reviewed-by:,
essentially.

Some reviewers explicitly state "With this and that nit corrected or
left as-is, the patch is Reviewed-by: me" to tell you that as long
as the difference between the version reviewed and the updated one
is limited within the named issues, you can add Reviewed-by: to your
rerolled patch.

In this case, I think the nits are pretty small and I do not mind
tweaking the version we are discussing on my end, without having you
to send an updated one.

Here is what I'd squash into your commit, with title corrected, if
you are OK with that plan.  In the meantime, I'll keep the following
as a separate patch on top when I merge your fix to 'pu'.

Thanks.

 t/t1500-rev-parse.sh | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh
index b774cafc5d..01abee533d 100755
--- a/t/t1500-rev-parse.sh
+++ b/t/t1500-rev-parse.sh
@@ -134,6 +134,7 @@ test_expect_success 'rev-parse --is-shallow-repository in non-shallow repo' '
 test_expect_success 'showing the superproject correctly' '
 	git rev-parse --show-superproject-working-tree >out &&
 	test_must_be_empty out &&
+
 	test_create_repo super &&
 	test_commit -C super test_commit &&
 	test_create_repo sub &&
@@ -142,20 +143,20 @@ test_expect_success 'showing the superproject correctly' '
 	echo $(pwd)/super >expect  &&
 	git -C super/dir/sub rev-parse --show-superproject-working-tree >out &&
 	test_cmp expect out &&
+
 	test_commit -C super submodule_add &&
 	git -C super checkout -b branch1 &&
 	git -C super/dir/sub checkout -b branch1 &&
 	test_commit -C super/dir/sub branch1_commit &&
 	git -C super add dir/sub &&
 	test_commit -C super branch1_commit &&
-	git -C super checkout master &&
-	git -C super checkout -b branch2 &&
-	git -C super/dir/sub checkout master &&
-	git -C super/dir/sub checkout -b branch2 &&
+	git -C super checkout -b branch2 master &&
+	git -C super/dir/sub checkout -b branch2 master &&
 	test_commit -C super/dir/sub branch2_commit &&
 	git -C super add dir/sub &&
 	test_commit -C super branch2_commit &&
 	test_must_fail git -C super merge branch1 &&
+
 	git -C super/dir/sub rev-parse --show-superproject-working-tree >out &&
 	test_cmp expect out
 '

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

[Sam McKelvie]

> On Sep 27, 2018, at 6:43 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 
> Sam McKelvie <sammck@gmail.com> writes:
> 
>>>> Subject: Re: [PATCH] submodule: Alllow staged changes for get_superproject_working_tree
>>> 
>>> s/Alllow/allow/;
>>> 
>> 
>> Ok, no caps on first letter of subject.
> 
> Ah, that, too.  I meant to correct triple ell, though ;-)
> 
> When one reviewer says Reviewed-by: but you later found that the
> patch was not good enough to deserve a redoing, feel free to redo
> the patch and do not add the Reviewed-by: you got for the old one
> to your second submission.  The difference between the one that was
> reviewed and the one you updated invalidates the stale Reviewed-by:,
> essentially.
> 
> Some reviewers explicitly state "With this and that nit corrected or
> left as-is, the patch is Reviewed-by: me" to tell you that as long
> as the difference between the version reviewed and the updated one
> is limited within the named issues, you can add Reviewed-by: to your
> rerolled patch.
> 
> In this case, I think the nits are pretty small and I do not mind
> tweaking the version we are discussing on my end, without having you
> to send an updated one.
> 
> Here is what I'd squash into your commit, with title corrected, if
> you are OK with that plan.  In the meantime, I'll keep the following
> as a separate patch on top when I merge your fix to 'pu'.
> 
> Thanks.

I wholeheartedly approve of that plan and your tweaking commit below. Thank you, Junio.

~Sam

> 
> t/t1500-rev-parse.sh | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/t/t1500-rev-parse.sh b/t/t1500-rev-parse.sh
> index b774cafc5d..01abee533d 100755
> --- a/t/t1500-rev-parse.sh
> +++ b/t/t1500-rev-parse.sh
> @@ -134,6 +134,7 @@ test_expect_success 'rev-parse --is-shallow-repository in non-shallow repo' '
> test_expect_success 'showing the superproject correctly' '
> 	git rev-parse --show-superproject-working-tree >out &&
> 	test_must_be_empty out &&
> +
> 	test_create_repo super &&
> 	test_commit -C super test_commit &&
> 	test_create_repo sub &&
> @@ -142,20 +143,20 @@ test_expect_success 'showing the superproject correctly' '
> 	echo $(pwd)/super >expect  &&
> 	git -C super/dir/sub rev-parse --show-superproject-working-tree >out &&
> 	test_cmp expect out &&
> +
> 	test_commit -C super submodule_add &&
> 	git -C super checkout -b branch1 &&
> 	git -C super/dir/sub checkout -b branch1 &&
> 	test_commit -C super/dir/sub branch1_commit &&
> 	git -C super add dir/sub &&
> 	test_commit -C super branch1_commit &&
> -	git -C super checkout master &&
> -	git -C super checkout -b branch2 &&
> -	git -C super/dir/sub checkout master &&
> -	git -C super/dir/sub checkout -b branch2 &&
> +	git -C super checkout -b branch2 master &&
> +	git -C super/dir/sub checkout -b branch2 master &&
> 	test_commit -C super/dir/sub branch2_commit &&
> 	git -C super add dir/sub &&
> 	test_commit -C super branch2_commit &&
> 	test_must_fail git -C super merge branch1 &&
> +
> 	git -C super/dir/sub rev-parse --show-superproject-working-tree >out &&
> 	test_cmp expect out
> '

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

[Junio C Hamano]

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.

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

[Sam McKelvie]

> On Sep 28, 2018, at 11:00 AM, Junio C Hamano <gitster@pobox.com> wrote:
> 
> 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.
> 
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.

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

[Junio C Hamano]

Sam McKelvie <sammck@gmail.com> writes:

>> 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

I've pushed out with the "rev-parse: ..." as the title.

Thanks for the fix.