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: "Timothy Pearson" <kb9vqf@...>
Date: Fri, 17 Feb 2012 10:36:06 -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 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