As Chris pointed out, submodules work precisely this way (detached head), so every time I have to manually bump the commits to what is available in the latest repos, so the chances it is not what is the latest upstream is high.
So one could argue that this is what the script should do (checkout master and stuff). If you want to make a small patch for that, I'd include it. Thanks, Lucas On Fri, Mar 22, 2013 at 1:13 PM, Gawlas, Julius <[email protected]> wrote: > Chris, > > Thanks for the explanation. > > Should the installer script do that (git checkout master, etc)? It calls > test_importer after initializing the subrepos but at that point they are in > that state described below with the tests that are not what is latest > upstream? > > Julius > > -----Original Message----- > From: Chris Evich [mailto:[email protected]] > Sent: Friday, March 22, 2013 6:47 AM > To: Gawlas, Julius > Cc: [email protected] > Subject: Re: [Autotest] installer script, initializing test repos into > submodules question > > On 03/21/2013 09:26 PM, Gawlas, Julius wrote: >> The installer script (install-autotest-server.sh) initializes >> submodules using >> >> $ git submodule init $ git submodule update --recursive >> >> Which puts the tests repos in headless state (according to git docs - >> I am certainly not a git expert) and it is neither master or next as I >> can see differences between what is local and remotes/origin/next and >> remotes/origin/master. That is confusing and causes test failures as >> aiostress has been recently updated. >> >> No big deal we can just checkout master on the server but that does >> not look like intended behavior? >> >> Also another minor thing in autotest-client-tests / bonnie; looks like >> the lastest change went straingt to master and it is not part of next >> (upgrade to 1.96) >> >> Julius > > The headless state is just after updating. You shouldn't ever need to touch > the submodule stuff again. Just directly git checkout master or next from > each repo & sub-repo and it will create a local tracking branch. From there, > doing a 'git remote update origin' will make your local master/next branch > aware of new upstream changes. You can then bring those changes in to local > branches with the standard cherry-pick, rebase, and reset commands. Don't > forget you need to do this for each repo seperatly, even though they're > nested. > > -- > Chris Evich, RHCA, RHCE, RHCDS, RHCSS > Quality Assurance Engineer > e-mail: cevich + `@' + redhat.com o: 1-888-RED-HAT1 x44214 > > _______________________________________________ > Autotest-kernel mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/autotest-kernel -- Lucas _______________________________________________ Autotest-kernel mailing list [email protected] https://www.redhat.com/mailman/listinfo/autotest-kernel
