{"thread":{"id":"41499","subject":"Git submodule regression in 2.7.0+","startedAt":"2016-02-24T19:35:37Z","lastAt":"2016-02-24T20:53:44Z","messageCount":2,"participants":["Caleb Jorden","Stefan Beller"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"279167","messageId":"CABD8wQkN8bLQzqtUru9X+Mxji8U4UoUVdiioCNrJsWEzwcL50g@mail.gmail.com","threadId":"41499","inReplyTo":null,"subject":"Git submodule regression in 2.7.0+","fromName":"Caleb Jorden","fromEmail":"cjorden@gmail.com","sentAt":"2016-02-24T19:35:37Z","receivedAt":"2016-02-24T19:35:37Z","isPatch":false,"sender":{"key":"cjorden@gmail.com","avatar":null},"body":"Git community,\n\nI have hit a rather significant regression in recent versions of Git,\nwhen using submodules.  I have narrowed it down to a simple set of\ncommands that demonstrates the problem (commands for a unix-style OS):\n\n---- Start list of commands to reproduce issue ----\nmkdir -p test/a/b\ncd test\ngit init\ncd a/b\ngit init\necho hello > testfile1\ngit add .\ngit commit -m \"test1\"\ncd ../..\nmkdir -p 1/b\ncd 1/b\ngit init\necho hi > testfile2\ngit add .\ngit commit -m \"test2\"\ncd ../..\ngit submodule add /a/b a/b\ngit submodule add /1/b 1/b\ngit commit -m \"first submodule commit\"\ngit submodule--helper list a/b\n---- End list of commands ----\n\nOn my machines, this shows 1/b, not a/b.\n\nIt seems that the submodule--helper (at least for the list command) is\nnot properly taking into account the path in the repository, but\nrather just the submodule name itself.\n\nThis manifests itself if you have a Git repo that uses submodules that\nhas been updated (or just cloned), and you want to specifically update\na single submodule (which is where this problem was discovered).  If\nyou run in \"git submodule update <submodule path>\", and you have two\nsubmodules with the same name (but in different paths in the\nrepository), then you will update the first one found\n(lexicographically, as far as I can tell), every time.  There may be\nother operations on submodules that are impacted as well, but I have\nnot explored them completely.\n\nThis may seem like a contrived situation, but this problem was found\nin a live repo that uses submodules (albeit a private one).\n\nNote that this behavior changed in 2.7.0 and is still current (happens\nin 2.7.1, 2.7.2, and master in git repo as of 2/23/2016).  Prior to\n2.7.0 (which introduced the submodule--helper command) the behavior\nfor this was as expected - the entire path was taken into account for\nthe submodule update command.  This has been observed on a Gentoo\nmachine (x86_64), as well as numerous Ubuntu installs (x86_64, 14.04).\nThis occurs both with the ubuntu git PPA (Git stable releases \"Ubuntu\nGit Maintainers\" team, 2.7.1 at the time of this writing) and from a\nfresh compile of 2.7.2 from source.\n\nThis regression can be fixed in 2.7.2 if one reverts the three commits\nwhich introduced submodule--helper.c file and associated changes\n(ee8838d157761acf4cc38f2378277dc894c10eb0,\n0ea306ef1701d6f42e74d3c33addfcd630248904, and\n74703a1e4dfc5affcb8944e78b53f0817b492246).  Just to be clear, I am not\nadvocating reverting these changes - I would rather see the\nsubmodule--helper.c work continue, but also see this fixed.\n\nI have not yet had the time to dive into the code to find what the\nproblem is, but I wanted to make sure this was reported so that others\nwho may be hitting this can be aware of it.  Also, I wanted to make\nStefan Beller aware of this, as he seems to still be working on the\nsubmodule--helper.c code.\n\nI am not currently subscribed to the Git mailing list, so please CC me\nin any response.\n\nRegards,\n\nCaleb Jorden\ncjorden@gmail.com\n"},{"id":"279175","messageId":"CAGZ79kY4X8Df0wHYka9AVcjBp3LXJ=LG220YjJYmL0C5aSYbBA@mail.gmail.com","threadId":"41499","inReplyTo":"CABD8wQkN8bLQzqtUru9X+Mxji8U4UoUVdiioCNrJsWEzwcL50g@mail.gmail.com","subject":"Re: Git submodule regression in 2.7.0+","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2016-02-24T20:53:44Z","receivedAt":"2016-02-24T20:53:44Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Wed, Feb 24, 2016 at 11:35 AM, Caleb Jorden <cjorden@gmail.com> wrote:\n> Git community,\n>\n> I have hit a rather significant regression in recent versions of Git,\n> when using submodules.  I have narrowed it down to a simple set of\n> commands that demonstrates the problem (commands for a unix-style OS):\n>\n> ---- Start list of commands to reproduce issue ----\n> mkdir -p test/a/b\n> cd test\n> git init\n> cd a/b\n> git init\n> echo hello > testfile1\n> git add .\n> git commit -m \"test1\"\n> cd ../..\n> mkdir -p 1/b\n> cd 1/b\n> git init\n> echo hi > testfile2\n> git add .\n> git commit -m \"test2\"\n> cd ../..\n> git submodule add /a/b a/b\n> git submodule add /1/b 1/b\n> git commit -m \"first submodule commit\"\n> git submodule--helper list a/b\n> ---- End list of commands ----\n>\n> On my machines, this shows 1/b, not a/b.\n>\n> It seems that the submodule--helper (at least for the list command) is\n> not properly taking into account the path in the repository, but\n> rather just the submodule name itself.\n\nThe error is in submodule--helper.c module_list_compute 45\nwhere I would expect\n\n    if (!S_ISGITLINK(ce->ce_mode) ||\n       !match_pathspec(pathspec, ce->name, ce_namelen(ce),\n       max_prefix_len, ps_matched, 1))\n        continue;\n\nto fail if ce->name== 1/b and the pathspec is setup for a/b.\n(I verified these using gdb, the condition doesn't trigger and\ncontinues in the code instead of following the 'continue' statement.\n\nMaybe the setup of the 'pathspec' is wrong using the flags\n\n    parse_pathspec(pathspec, 0,\n          PATHSPEC_PREFER_FULL |\n          PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP,\n          prefix, argv);\n\n>\n> This manifests itself if you have a Git repo that uses submodules that\n> has been updated (or just cloned), and you want to specifically update\n> a single submodule (which is where this problem was discovered).  If\n> you run in \"git submodule update <submodule path>\", and you have two\n> submodules with the same name (but in different paths in the\n> repository), then you will update the first one found\n> (lexicographically, as far as I can tell), every time.  There may be\n> other operations on submodules that are impacted as well, but I have\n> not explored them completely.\n\nNearly all 'git submodule <commands>' use 'git submodule--helper list',\nso I'd expect other breakages indeed.\n\n\n>\n> This may seem like a contrived situation, but this problem was found\n> in a live repo that uses submodules (albeit a private one).\n>\n> Note that this behavior changed in 2.7.0 and is still current (happens\n> in 2.7.1, 2.7.2, and master in git repo as of 2/23/2016).  Prior to\n> 2.7.0 (which introduced the submodule--helper command) the behavior\n> for this was as expected - the entire path was taken into account for\n> the submodule update command.  This has been observed on a Gentoo\n> machine (x86_64), as well as numerous Ubuntu installs (x86_64, 14.04).\n> This occurs both with the ubuntu git PPA (Git stable releases \"Ubuntu\n> Git Maintainers\" team, 2.7.1 at the time of this writing) and from a\n> fresh compile of 2.7.2 from source.\n>\n> This regression can be fixed in 2.7.2 if one reverts the three commits\n> which introduced submodule--helper.c file and associated changes\n> (ee8838d157761acf4cc38f2378277dc894c10eb0,\n> 0ea306ef1701d6f42e74d3c33addfcd630248904, and\n> 74703a1e4dfc5affcb8944e78b53f0817b492246).  Just to be clear, I am not\n> advocating reverting these changes - I would rather see the\n> submodule--helper.c work continue, but also see this fixed.\n>\n> I have not yet had the time to dive into the code to find what the\n> problem is, but I wanted to make sure this was reported so that others\n> who may be hitting this can be aware of it.  Also, I wanted to make\n> Stefan Beller aware of this, as he seems to still be working on the\n> submodule--helper.c code.\n\nThanks for pointing out the problem, I'll look into it.\nSorry to break your use case.\n\n>\n> I am not currently subscribed to the Git mailing list, so please CC me\n> in any response.\n\nThanks,\nStefan\n>\n> Regards,\n>\n> Caleb Jorden\n> cjorden@gmail.com\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n"}]}