Guys,
I have a local tree that I converted to 3.5.13-sru. However, not all of the modules switched to sru -- how did that happen? When I try a 'git pull' and 'git submodule init' I get:
Module: 'applications/abakus' - current local branch is already 'v3.5.13-sru' U admin U cmake U src/CMakeLists.txt Pull is not possible because you have unmerged files. Please, fix them up in the work tree, and then use 'git add/rm <file>' as appropriate to mark resolution, or use 'git commit -a'. Skipping unmerged submodule admin Skipping unmerged submodule cmake
I ran into a few build issues today on one box (can't find 'tde-config') and tracing it back, ran into this problem. I have another local tree that I converted to 3.5.13-sru and it went fine. Now I have to figure out how to 'fix' the one that didn't come all the way to 3513-sru. Here are the packages I'm having issues on:
(good) module: applications/desktop-effects-tde branch: v3.5.13-sru available: HEAD master v3.5.13-sru
(bad) applications/compizconfig-backend-kconfig branch: master available: HEAD master (it doesn't eve show v3.5.13-sru available)
(good) applications/kaffeine-mozilla branch: v3.5.13-sru available: HEAD master v3.5.13-sru
(bad) applications/kaffeine-mozilla branch: master available: HEAD master
I don't get it ;( I do the same thing on the same packages, but then end up with one tree not going all the way to v3.5.13-sru.
To make the switch, I test the local branch against the remote branch, If local is not v3.5.13-sru and remote has v3.5.13-sru available, then I do:
git checkout v3.5.13-sru # to switch git pull git submodule update
If v3.5.13-sru isn't immediately returned as available, then I try:
## normal reset to head, discard local edits and update git reset --hard HEAD git clean -dxf git pull git reset --hard HEAD git clean -dxf sed -i "s/system@/${gituser}@/g" .gitmodules git submodule init git submodule update --recursive git submodule foreach --recursive "git checkout master" git submodule foreach --recursive "git pull" git checkout -- .gitmodules
followed by
git checkout v3.5.13-sru # to switch git pull git submodule update
Somehow that has ended up with abakus and about 4 other packages in a state where a git pull results in:
Module: 'applications/abakus' - current local branch is already 'v3.5.13-sru' U admin U cmake U src/CMakeLists.txt Pull is not possible because you have unmerged files. Please, fix them up in the work tree, and then use 'git add/rm <file>' as appropriate to mark resolution, or use 'git commit -a'. Skipping unmerged submodule admin Skipping unmerged submodule cmake
So how to fix? I'm just bewildered by the whole GIT personality....
On 08/15/2012 12:41 AM, David C. Rankin wrote:
Guys,
I have a local tree that I converted to 3.5.13-sru. However, not all of the modules switched to sru -- how did that happen? When I try a 'git pull' and 'git submodule init' I get:
Module: 'applications/abakus' - current local branch is already 'v3.5.13-sru' U admin U cmake U src/CMakeLists.txt Pull is not possible because you have unmerged files. Please, fix them up in the work tree, and then use 'git add/rm <file>' as appropriate to mark resolution, or use 'git commit -a'. Skipping unmerged submodule admin Skipping unmerged submodule cmake
I think I have it sorted. Before making a switch from master -> v3.5.13-sru, your GIT tree must be fully updated to not miss a commit that is relevant to the new branch. I first converted the problem branch a week or two ago before many of the v3.5.13-sru branch was created for several packages. Then when attempting to switch and update all modules today, I hit that situation and git failed to see a v3.5.13-sru branch available and refused the git pull. Adding the following:
## get remote branches available and parse for branch name gitremotebranches if [[ ! "${remba[@]}" =~ "$branch" ]]; then gitresetHEAD master gitremotebranches fi
uses git branch -r to getremotebranches to fill the $remba array and tests it against the substring "$branch" (v3.5.13-sru) to see if the branch is available remotely. If not, it then does a full reset of the package back to the current master with 'gitresetHEAD master'. It then again obtains the remote branches available and proceed to switch to v3.5.13-sru if it is contained in the new remote branch array. Seems to have worked nicely.
The gitresetHEAD() function is shown below for completeness.
## function - reset current module to HEAD and update gitresetHEAD() {
## normal reset to head, discard local edits and update git reset --hard HEAD git clean -dxf git pull git reset --hard HEAD git clean -dxf sed -i "s/system@/${gituser}@/g" .gitmodules git submodule init git submodule update --recursive git submodule foreach --recursive "git checkout "$1"" git submodule foreach --recursive "git pull" git checkout -- .gitmodules
}
-
David C. Rankin