17 Feb
2012
17 Feb
'12
4:37 a.m.
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.
17 Feb
17 Feb
4:44 a.m.
New subject: [trinity-devel] Could git version mismatches be responsible for the borked git clone experiences?
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?
--
David C. Rankin, J.D.,P.E.
5:04 a.m.
New subject: [trinity-devel] Could git version mismatches be responsible for the borked git clone experiences?
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
11:38 a.m.
New subject: [trinity-devel] Could git version mismatches be responsible for the borked git clone experiences?
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(a)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(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)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
3:17 p.m.
New subject: [trinity-devel] Could git version mismatches be responsible for the borked git clone experiences?
On 02/16/2012 11:04 PM, Timothy Pearson wrote:
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)
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(a)lists.pearsoncomputing.net
For additional commands, e-mail: trinity-devel-help(a)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
--
David C. Rankin, J.D.,P.E.
4:36 p.m.
New subject: [trinity-devel] Could git version mismatches be responsible for the borked git clone experiences?
On 02/16/2012 11:04 PM, Timothy Pearson wrote:
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
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
5:14 p.m.
New subject: [trinity-devel] Could git version mismatches be responsible for the borked git clone experiences?
On 02/17/2012 10:36 AM, Timothy Pearson wrote:
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, J.D.,P.E.
> 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.
4696
days inactive
4696
days old
6 comments
3 participants
participants (3)
-
David C. Rankin -
Jay -
Timothy Pearson