trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: February 2012

Re: [trinity-devel] Could git version mismatches be responsible for the borked git clone experiences?

From: "David C. Rankin" <drankinatty@...>
Date: Fri, 17 Feb 2012 09:17:14 -0600
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@...
> For additional commands, e-mail: trinity-devel-help@...
> 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.