{"thread":{"id":"51486","subject":"[BUG] Recursive submodules fails to track branch correctly if . is used","startedAt":"2019-07-16T21:49:51Z","lastAt":"2019-07-16T21:49:51Z","messageCount":1,"participants":["Krzysztof Opasiak"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"378995","messageId":"08844c07-5192-0645-9bfc-62e1b16e39a8@samsung.com","threadId":"51486","inReplyTo":"CGME20190716214945eucas1p299e23651b7bc1738d0c3bf2d227d4e46@eucas1p2.samsung.com","subject":"[BUG] Recursive submodules fails to track branch correctly if . is used","fromName":"Krzysztof Opasiak","fromEmail":"k.opasiak@samsung.com","sentAt":"2019-07-16T21:49:43Z","receivedAt":"2019-07-16T21:49:51Z","isPatch":false,"sender":{"key":"k.opasiak@samsung.com","avatar":null},"body":"Dear git community,\n\nI'd like to report you a potential bug in git submodule implementation.\n\n* Problem statement\n\nAccording to doc a special value of \".\" can be used as a branch name to \ntrack. This means that git should trace the same branch as is currently \nin use in superproject. This works perfectly fine as long as you don't \ntry to add superproject (SUP1) with such configuration as a submodule to \nanother superproject (SUP2). The nesting structure would look like this:\n\nSUP2\n     - SUP1\n         - SUB_PROJECT\n\nIf you try to do this you won't be able to execute any of the following \ncommands:\n\n$ git clone --recursive SUP2\n\n$ git clone SUP2 & git submodule update --init --recursive --remote\n\n$ git submodule update --init --recursive --remote\n\nas every time you will get an error message similar to this one:\n\nfatal: Submodule (SUB_PROJECT) branch configured to inherit branch from \nsuperproject, but the superproject is not on any branch\nfatal: Needed a single revision\nUnable to find current origin/ revision in submodule path 'SUB_PROJECT'\n\n* Initial investigation results\n\nThe error message comes from remote_submodule_branch():1938 in \nsubmodule--helper.c and it is generated called from SUP1 dir (due to \n--recursive flag). Actually this function behaves correctly. If you go \nto SUP1 dir and check the branch info you will notice that the repo is \nin detached head state.\n\n* Probable root cause\n\nThe root cause is that the traced branch information is never propagated \nto the submodules. All the submodules are always initialized in a \ndetached head state and there is no way to change this behavior nor to \npropagate the traced branch information to submodules.\n\n* Workaround script\n\nI managed to workaround this bug by dropping the recursive option and \nafter the top level project has been cloned I go through every \nsubmodule, set local branch to point to current head and then just do \ngit checkout and I do this recursively in all modules. After this I'm \nable to successfully execute:\n\n$ git submodule update --rebase --recursive --remote\n\nThe script (to be executed in SUP2 right after clone):\n\n#!/bin/bash\n\nfunction prepare_submodules {\n\tgit submodule update --init\n\tlocal SUBMODULE_LIST=`git submodule--helper status | awk '{print $2}'`\n\twhile read -r submod; do\n\t\tlocal PARENT_DIR=`pwd`\n\t\tlocal BRANCH=`git submodule--helper remote-branch ${submod}`\n\n\t\tcd ${submod}\n\t\tgit branch -f ${BRANCH} HEAD;\n\t\tgit checkout ${BRANCH}\n\t\tif [ ! -z \"`git submodule status`\" ]; then\n\t\t\tprepare_submodules;\n\t\tfi\n\t\tcd ${PARENT_DIR}\n\tdone <<< \"$SUBMODULE_LIST\"\n}\n\nprepare_submodules\n\nBest regards,\n-- \nKrzysztof Opasiak\nSamsung R&D Institute Poland\nSamsung Electronics\n"}]}