{"thread":{"id":"50235","subject":"Inconsistent Behavior using 'Reference'","startedAt":"2019-01-15T22:24:17Z","lastAt":"2019-01-25T17:20:08Z","messageCount":3,"participants":["Bret Barkelew"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"366771","messageId":"CAGTkKagdG=85CVZbumVfXHTx6zgmbD6_PHmzPx4rFpdZ+c22Gg@mail.gmail.com","threadId":"50235","inReplyTo":null,"subject":"Inconsistent Behavior using 'Reference'","fromName":"Bret Barkelew","fromEmail":"bret@corthon.com","sentAt":"2019-01-15T22:24:03Z","receivedAt":"2019-01-15T22:24:17Z","isPatch":false,"sender":{"key":"bret@corthon.com","avatar":"https://gravatar.com/avatar/9a370be172af79638f919295074527b53afe3147b7df1251a45ae93d6498f376?d=mp&s=160"},"body":"The repo/workspace (not the cache, the code we’re going to build) that\nwe’re trying to initialize uses several submodules. We’ve notice that\nif we use ‘clone’ first on the parent repository, then call ‘git\nsubmodule update --init --recursive --reference <path>’ inside the\nparent repository, the same path is passed to all child and nested\nchild repositories.\n\nHowever, if we call ‘git clone --recurse-submodules --reference\n<path>’ and try to clone the parent and initialize submodules in one\nstep, Git tries to append the submodule relative path (relative to the\nparent) to each of the recursive calls, and since the reference repo\nis bare, this fails.\n\nCRITICAL - Cloning repo: https://github.com/Microsoft/mu_tiano_plus.git\nINFO - Cmd to run is: git clone --recurse-submodules --reference\nC:\\src2\\mu4\\mu_basecore https://github.com/Microsoft/mu_tiano_plus.git\nC:\\src2\\mu4\\mu_basecore\\Common\\TIANO\nINFO - ------------------------------------------------\nINFO - --------------Cmd Output Starting---------------\nINFO - ------------------------------------------------\nINFO - Cloning into 'C:\\src2\\mu4\\mu_basecore\\Common\\TIANO'...\nChecking out files: 100% (3858/3858), done.\nINFO - Submodule 'CryptoPkg/Library/OpensslLib/openssl'\n(https://github.com/openssl/openssl) registered for path\n'CryptoPkg/Library/OpensslLib/openssl'\nINFO - fatal: submodule 'CryptoPkg/Library/OpensslLib/openssl' cannot\nadd alternate: path\n'C:/src2/mu4/mu_basecore/.git/modules/CryptoPkg/Library/OpensslLib/openssl/'\ndoes not exist\nINFO - Failed to clone 'CryptoPkg/Library/OpensslLib/openssl'. Retry scheduled\nINFO - fatal: submodule 'CryptoPkg/Library/OpensslLib/openssl' cannot\nadd alternate: path\n'C:/src2/mu4/mu_basecore/.git/modules/CryptoPkg/Library/OpensslLib/openssl/'\ndoes not exist\nINFO - Failed to clone 'CryptoPkg/Library/OpensslLib/openssl' a second\ntime, aborting\n\nAs you can see, the parent path is\n‘'C:\\src2\\mu4\\mu_basecore\\Common\\TIANO’, but when clone initializes\nthe submodule, it updates the ‘C:\\src2\\mu4\\mu_basecore’ reference to\n‘C:/src2/mu4/mu_basecore/.git/modules/CryptoPkg/Library/OpensslLib/openssl/’,\nas though the reference were a full repo and it was checking for the\nsubmodule repo within the ‘.git’ directory.\n\nIf we do this same thing using a ‘clone’ first, and ‘submodule update’\nsecond, the same ‘C:\\src2\\mu4\\mu_basecore’ reference is passed to all\nsubmodules (AND nested submodules).\n\nThoughts? Are these both expected behaviors? Will they be consistent\nin future versions of git?\n\nThanks!\n\n- Bret Barkelew\n"},{"id":"367180","messageId":"CAGTkKahN+bvhhhu+upLNUnMMvmg7fxYqKeYwHAKO3-LZp9rfuw@mail.gmail.com","threadId":"50235","inReplyTo":"CAGTkKagdG=85CVZbumVfXHTx6zgmbD6_PHmzPx4rFpdZ+c22Gg@mail.gmail.com","subject":"Re: Inconsistent Behavior using 'Reference'","fromName":"Bret Barkelew","fromEmail":"bret@corthon.com","sentAt":"2019-01-19T18:38:10Z","receivedAt":"2019-01-19T18:38:26Z","isPatch":false,"sender":{"key":"bret@corthon.com","avatar":"https://gravatar.com/avatar/9a370be172af79638f919295074527b53afe3147b7df1251a45ae93d6498f376?d=mp&s=160"},"body":"Bump.\n\nWe really do need to figure this out. Anyone familiar with the\nbehavior of “reference”?\n\nThanks!\n\nOn Tue, Jan 15, 2019 at 2:24 PM Bret Barkelew <bret@corthon.com> wrote:\n>\n> The repo/workspace (not the cache, the code we’re going to build) that\n> we’re trying to initialize uses several submodules. We’ve notice that\n> if we use ‘clone’ first on the parent repository, then call ‘git\n> submodule update --init --recursive --reference <path>’ inside the\n> parent repository, the same path is passed to all child and nested\n> child repositories.\n>\n> However, if we call ‘git clone --recurse-submodules --reference\n> <path>’ and try to clone the parent and initialize submodules in one\n> step, Git tries to append the submodule relative path (relative to the\n> parent) to each of the recursive calls, and since the reference repo\n> is bare, this fails.\n>\n> CRITICAL - Cloning repo: https://github.com/Microsoft/mu_tiano_plus.git\n> INFO - Cmd to run is: git clone --recurse-submodules --reference\n> C:\\src2\\mu4\\mu_basecore https://github.com/Microsoft/mu_tiano_plus.git\n> C:\\src2\\mu4\\mu_basecore\\Common\\TIANO\n> INFO - ------------------------------------------------\n> INFO - --------------Cmd Output Starting---------------\n> INFO - ------------------------------------------------\n> INFO - Cloning into 'C:\\src2\\mu4\\mu_basecore\\Common\\TIANO'...\n> Checking out files: 100% (3858/3858), done.\n> INFO - Submodule 'CryptoPkg/Library/OpensslLib/openssl'\n> (https://github.com/openssl/openssl) registered for path\n> 'CryptoPkg/Library/OpensslLib/openssl'\n> INFO - fatal: submodule 'CryptoPkg/Library/OpensslLib/openssl' cannot\n> add alternate: path\n> 'C:/src2/mu4/mu_basecore/.git/modules/CryptoPkg/Library/OpensslLib/openssl/'\n> does not exist\n> INFO - Failed to clone 'CryptoPkg/Library/OpensslLib/openssl'. Retry scheduled\n> INFO - fatal: submodule 'CryptoPkg/Library/OpensslLib/openssl' cannot\n> add alternate: path\n> 'C:/src2/mu4/mu_basecore/.git/modules/CryptoPkg/Library/OpensslLib/openssl/'\n> does not exist\n> INFO - Failed to clone 'CryptoPkg/Library/OpensslLib/openssl' a second\n> time, aborting\n>\n> As you can see, the parent path is\n> ‘'C:\\src2\\mu4\\mu_basecore\\Common\\TIANO’, but when clone initializes\n> the submodule, it updates the ‘C:\\src2\\mu4\\mu_basecore’ reference to\n> ‘C:/src2/mu4/mu_basecore/.git/modules/CryptoPkg/Library/OpensslLib/openssl/’,\n> as though the reference were a full repo and it was checking for the\n> submodule repo within the ‘.git’ directory.\n>\n> If we do this same thing using a ‘clone’ first, and ‘submodule update’\n> second, the same ‘C:\\src2\\mu4\\mu_basecore’ reference is passed to all\n> submodules (AND nested submodules).\n>\n> Thoughts? Are these both expected behaviors? Will they be consistent\n> in future versions of git?\n\nIf we were to converge on one, we would prefer the single path rather\nthan the inferred path.\n\n>\n> Thanks!\n>\n> - Bret Barkelew\n"},{"id":"367668","messageId":"CAGTkKajuzthVJuhmi9ghNAV9LQoTcUMpbDh0J7y7ePpVw0xW_Q@mail.gmail.com","threadId":"50235","inReplyTo":"CAGTkKahN+bvhhhu+upLNUnMMvmg7fxYqKeYwHAKO3-LZp9rfuw@mail.gmail.com","subject":"Re: Inconsistent Behavior using 'Reference'","fromName":"Bret Barkelew","fromEmail":"bret@corthon.com","sentAt":"2019-01-25T17:19:54Z","receivedAt":"2019-01-25T17:20:08Z","isPatch":false,"sender":{"key":"bret@corthon.com","avatar":"https://gravatar.com/avatar/9a370be172af79638f919295074527b53afe3147b7df1251a45ae93d6498f376?d=mp&s=160"},"body":"Bump x 2\n\nStill seeking anyone that understands the logic behind how \"reference\"\nworks across multiple commands.\n\nThanks!\n- Bret\n\nOn Sat, Jan 19, 2019 at 10:38 AM Bret Barkelew <bret@corthon.com> wrote:\n>\n> Bump.\n>\n> We really do need to figure this out. Anyone familiar with the\n> behavior of “reference”?\n>\n> Thanks!\n>\n> On Tue, Jan 15, 2019 at 2:24 PM Bret Barkelew <bret@corthon.com> wrote:\n> >\n> > The repo/workspace (not the cache, the code we’re going to build) that\n> > we’re trying to initialize uses several submodules. We’ve notice that\n> > if we use ‘clone’ first on the parent repository, then call ‘git\n> > submodule update --init --recursive --reference <path>’ inside the\n> > parent repository, the same path is passed to all child and nested\n> > child repositories.\n> >\n> > However, if we call ‘git clone --recurse-submodules --reference\n> > <path>’ and try to clone the parent and initialize submodules in one\n> > step, Git tries to append the submodule relative path (relative to the\n> > parent) to each of the recursive calls, and since the reference repo\n> > is bare, this fails.\n> >\n> > CRITICAL - Cloning repo: https://github.com/Microsoft/mu_tiano_plus.git\n> > INFO - Cmd to run is: git clone --recurse-submodules --reference\n> > C:\\src2\\mu4\\mu_basecore https://github.com/Microsoft/mu_tiano_plus.git\n> > C:\\src2\\mu4\\mu_basecore\\Common\\TIANO\n> > INFO - ------------------------------------------------\n> > INFO - --------------Cmd Output Starting---------------\n> > INFO - ------------------------------------------------\n> > INFO - Cloning into 'C:\\src2\\mu4\\mu_basecore\\Common\\TIANO'...\n> > Checking out files: 100% (3858/3858), done.\n> > INFO - Submodule 'CryptoPkg/Library/OpensslLib/openssl'\n> > (https://github.com/openssl/openssl) registered for path\n> > 'CryptoPkg/Library/OpensslLib/openssl'\n> > INFO - fatal: submodule 'CryptoPkg/Library/OpensslLib/openssl' cannot\n> > add alternate: path\n> > 'C:/src2/mu4/mu_basecore/.git/modules/CryptoPkg/Library/OpensslLib/openssl/'\n> > does not exist\n> > INFO - Failed to clone 'CryptoPkg/Library/OpensslLib/openssl'. Retry scheduled\n> > INFO - fatal: submodule 'CryptoPkg/Library/OpensslLib/openssl' cannot\n> > add alternate: path\n> > 'C:/src2/mu4/mu_basecore/.git/modules/CryptoPkg/Library/OpensslLib/openssl/'\n> > does not exist\n> > INFO - Failed to clone 'CryptoPkg/Library/OpensslLib/openssl' a second\n> > time, aborting\n> >\n> > As you can see, the parent path is\n> > ‘'C:\\src2\\mu4\\mu_basecore\\Common\\TIANO’, but when clone initializes\n> > the submodule, it updates the ‘C:\\src2\\mu4\\mu_basecore’ reference to\n> > ‘C:/src2/mu4/mu_basecore/.git/modules/CryptoPkg/Library/OpensslLib/openssl/’,\n> > as though the reference were a full repo and it was checking for the\n> > submodule repo within the ‘.git’ directory.\n> >\n> > If we do this same thing using a ‘clone’ first, and ‘submodule update’\n> > second, the same ‘C:\\src2\\mu4\\mu_basecore’ reference is passed to all\n> > submodules (AND nested submodules).\n> >\n> > Thoughts? Are these both expected behaviors? Will they be consistent\n> > in future versions of git?\n>\n> If we were to converge on one, we would prefer the single path rather\n> than the inferred path.\n>\n> >\n> > Thanks!\n> >\n> > - Bret Barkelew\n"}]}