{"thread":{"id":"49412","subject":"\"git rev-parse --show-superproject-working-tree\" fails with \"fatal: BUG: returned path string doesn't match cwd?\" if supermodule has unmerged changes of the submodule reference","startedAt":"2018-09-24T17:59:34Z","lastAt":"2018-09-24T19:15:25Z","messageCount":2,"participants":["Sam McKelvie","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"358768","messageId":"EE3D88E4-EF86-44E2-811D-535C8F19C51A@gmail.com","threadId":"49412","inReplyTo":null,"subject":"\"git rev-parse --show-superproject-working-tree\" fails with \"fatal: BUG: returned path string doesn't match cwd?\" if supermodule has unmerged changes of the submodule reference","fromName":"Sam McKelvie","fromEmail":"sammck@gmail.com","sentAt":"2018-09-24T17:59:28Z","receivedAt":"2018-09-24T17:59:34Z","isPatch":false,"sender":{"key":"sammck@gmail.com","avatar":"https://avatars.githubusercontent.com/u/7035152?v=4"},"body":"I experienced this problem using git 2.17.1; however, from inspection of the next branch, function get_superproject_working_tree() in submodule.c has not changed in 2 years.\n\nI believe the problem is related to the fact that when a merge of the submodule reference is in progress, \"git --stage —full-name <submodule-relative-path>” returns three seperate entries for the submodule (one for each stage) rather than a single entry; e.g.,\n\n$ git ls-files --stage --full-name submodule-child-test\n160000 dbbd2766fa330fa741ea59bb38689fcc2d283ac5 1\tsubmodule-child-test\n160000 f174d1dbfe863a59692c3bdae730a36f2a788c51 2\tsubmodule-child-test\n160000 e6178f3a58b958543952e12824aa2106d560f21d 3\tsubmodule-child-test\n\nThe code in get_superproject_working_tree() uses the “-z” option on ls-files, so it expects null-byte termination between entries. However, the computation of super_sub_len:\n\n    \t\tsuper_sub_len = sb.buf + sb.len - super_sub - 1;\n\nwill only work when there is exactly one entry returned. If this line is changed to:\n\n\t\tsuper_sub_len = strlen(super_sub);\n\nthen only the first returned entry is used, and the bug is resolved.\n\nstrlen() should be safe to use here because strbuf_read ensures the result buffer is null-terminated.\n\nThanks,\nSam McKelvie\n\n\n"},{"id":"358774","messageId":"CAGZ79kZg8YLhNBoYJsB4ksbBtEMj3JvHs-qH7w930FiBDeVekQ@mail.gmail.com","threadId":"49412","inReplyTo":"EE3D88E4-EF86-44E2-811D-535C8F19C51A@gmail.com","subject":"Re: \"git rev-parse --show-superproject-working-tree\" fails with \"fatal: BUG: returned path string doesn't match cwd?\" if supermodule has unmerged changes of the submodule reference","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2018-09-24T19:15:10Z","receivedAt":"2018-09-24T19:15:25Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Mon, Sep 24, 2018 at 10:59 AM Sam McKelvie <sammck@gmail.com> wrote:\n>\n> I experienced this problem using git 2.17.1; however, from inspection of the next branch, function get_superproject_working_tree() in submodule.c has not changed in 2 years.\n>\n> I believe the problem is related to the fact that when a merge of the submodule reference is in progress, \"git --stage —full-name <submodule-relative-path>” returns three seperate entries for the submodule (one for each stage) rather than a single entry; e.g.,\n>\n> $ git ls-files --stage --full-name submodule-child-test\n> 160000 dbbd2766fa330fa741ea59bb38689fcc2d283ac5 1       submodule-child-test\n> 160000 f174d1dbfe863a59692c3bdae730a36f2a788c51 2       submodule-child-test\n> 160000 e6178f3a58b958543952e12824aa2106d560f21d 3       submodule-child-test\n>\n> The code in get_superproject_working_tree() uses the “-z” option on ls-files, so it expects null-byte termination between entries. However, the computation of super_sub_len:\n>\n>                 super_sub_len = sb.buf + sb.len - super_sub - 1;\n>\n> will only work when there is exactly one entry returned. If this line is changed to:\n>\n>                 super_sub_len = strlen(super_sub);\n>\n> then only the first returned entry is used, and the bug is resolved.\n>\n> strlen() should be safe to use here because strbuf_read ensures the result buffer is null-terminated.\n\nThis is good analysis of the issue. Thanks for writing it up!\nWould you also mind to send a patch fixing the problem?\n\nI agree that using strlen should work. I do not recall why I\ndid not use it at the time of writing it.\n\nThanks,\nStefan\n"}]}