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??
On 02/16/2012 10:37 PM, David C. Rankin wrote:
Still any idea what the cause of these issues are??
I have git 1.7.9.1-1 installed. Were there radical changes in the version that could explain the problems?
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
I am using git-1.7.4.4 and don't see such problems. Must be frustrating for you! I would downgrade and try a fresh git clone.
Jay
On Fri, Feb 17, 2012 at 5:04 AM, Timothy Pearson < kb9vqf@pearsoncomputing.net> 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
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
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 can't believe that the git versions some distros are so old. I checked and with arch, git passed 1.6.5 in 2009:
09:12 archangel:~> grep git /var/log/pacman.log <snip> [2009-07-30 13:58] installed git (1.6.4-1) <snip> [2009-10-12 01:59] upgraded git (1.6.4.4-1 -> 1.6.5-1) <snip> [2012-01-25 08:25] upgraded git (1.7.8.3-1 -> 1.7.8.4-1) [2012-02-07 10:14] upgraded git (1.7.8.4-1 -> 1.7.9-1) [2012-02-16 18:51] upgraded git (1.7.9-1 -> 1.7.9.1-1)
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
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
On 02/17/2012 10:36 AM, Timothy Pearson wrote:
On 02/16/2012 11:04 PM, Timothy Pearson wrote:
<snip>
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
That was it! The current 'git clone --recursive' is pulling in the submodules:
Cloning into 'main/tdebase'... remote: Counting objects: 23030, done remote: Finding sources: 100% (23030/23030) remote: Total 23030 (delta 14744), reused 23030 (delta 14744) Receiving objects: 100% (23030/23030), 32.38 MiB | 98 KiB/s, done. Resolving deltas: 100% (14744/14744), done. Submodule path 'main/tdebase': checked out '52d0d54062c878fac12cacab8ea9dbfe9c1da905' Submodule 'admin' (http://system@scm.trinitydesktop.org/scm/git/tde-common-admin) registered for path 'admin' Submodule 'cmake' (http://system@scm.trinitydesktop.org/scm/git/tde-common-cmake) registered for path 'cmake' Cloning into 'admin'... remote: Counting objects: 241, done remote: Finding sources: 100% (241/241) remote: Total 241 (delta 168), reused 241 (delta 168) Receiving objects: 100% (241/241), 396.63 KiB | 104 KiB/s, done. Resolving deltas: 100% (168/168), done. Submodule path 'admin': checked out '05d69037cede1f0db222b4dec81dda64f26fd8b3' Cloning into 'cmake'... remote: Counting objects: 281, done remote: Finding sources: 100% (281/281) remote: Total 281 (delta 179), reused 281 (delta 179) Receiving objects: 100% (281/281), 41.46 KiB, done. Resolving deltas: 100% (179/179), done. Submodule path 'cmake': checked out 'caedf8323c45b376c824de343f31de78664b2511'
I've updated the wiki.
http://www.trinitydesktop.org/wiki/bin/view/Developers/GIT
-
David C. Rankin -
Jay -
Timothy Pearson