15 Aug
2012
15 Aug
'12
5:41 a.m.
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....
--
David C. Rankin, J.D.,P.E.
15 Aug
15 Aug
6:19 a.m.
New subject: [trinity-devel] local tde GIT tree stuck -- How to fix?
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, J.D.,P.E.
4530
days inactive
4530
days old
1 comments
1 participants
participants (1)
-
David C. Rankin