On 02/16/2012 11:04 PM, Timothy Pearson wrote:
Guys,
I did a fresh git clone
http://scm.trinitydesktop.org/scm/git and the
git
clone resulted in the same empty 'admin' and 'cmake' files in the
directories
and in having and experimental/.git FILE instead of a DIR which hosed
the
shared
object use to fill them. switch_all_submodules_to_head_and_clean
crashed
on
experimental do I deleted and recloned experimental. Now I have a
proper
.git
DIRECTORY in experimental and the expected objects are present.
All other dependencies, applications, have .git FILES instead of .git
DIRECTORIES causing switch_all_submodules_to_head_and_clean to fail. If
I
delete
each submodule and then re-clone it again in the tree, the it will
contain
a
proper .git dir and will accept 'admin' and 'cmake' shared objects
allowing
build. But, I shouldn't have to pick through every submodule in TDE,
delete
recursive the submodule and then re-clone just to get the tree
straightened out
-- this is git -- it should just work. Still any idea what the cause of
these
issues are??
--
David C. Rankin, J.D.,P.E.
Sounds like a bug in the version of GIT you have installed. You could
check for buggy submodule handling in whatever version is installed...
It definitely should not be releated to the TDE project's GIT files,
aside
from the fact that we use submodules. :-)
Tim
Not a bug, a "Feature". With git version 1.6.5 or later, it seems you need
to use:
git clone --recursive http://<user>@scm.trinitydesktop.org/scm/git/tde
--recursive, --recurse-submodules
After the clone is created, initialize all submodules within, using their
default settings. This is equivalent to running git submodule update
--init
--recursive immediately after the clone is finished. This option is
ignored if
the cloned repository does not have a worktree/checkout (i.e. if any of
--no-checkout/-n, --bare, or --mirror is given)
I'm giving the --recursive option a shot as we speak. If it is the
problem,
the wiki needs updating. I'll see if I still have an active login and add
the info.
I was afraid of that. :-) At least there is an option (--recursive) to
use the old behaviour, making this purely a documentation issue as you
noted.
Tim