| Message ID | 20180927181054.25802-1-sammck@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | submodule: Alllow staged changes for get_superproject_working_tree | expand |
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
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.
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.
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 '
> 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 > '
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.
> 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.
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.
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 '
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(-)