[Users] ETK Maxwell checkout failing for McLachlan, KrancNumericalTools

Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] bernard.j.kelly at nasa.gov
Wed May 23 13:47:01 CDT 2012

Replying to myself here.

I noticed that my local Snow Leopard machine's git version ( is
close to that on my home Lion machine, so I tried a from-scratch checkout,
and had the same problem as at home. So it appears to be present with git
>= 1.7.10.X

I just verified that by removing the "--depth 1" option, the switch to
ET_2011_10 works (or at least doesn't produce any error message).

So for now, I'll be using --noshallow as Bruno does.

Thanks everyone,


On 5/23/12 2:16 PM, "Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND
BALTIMORE COUNTY]" <bernard.j.kelly at nasa.gov> wrote:

>Hi Ian.
>On 5/23/12 12:48 PM, "Ian Hinder" <ian.hinder at aei.mpg.de> wrote:
>>On 23 May 2012, at 17:40, Bruno C. Mundim wrote:
>>> Hi Beany/Ian:
>>>> I wonder if for some reason your new version of Git is honouring the
>>>>shallow clone option (--depth 1), whereas my old version is not.  I'm
>>>>not sure why we do a shallow clone by default;
>>> People were concerned with the size of the git repos and how slow would
>>> be to check them out. So there was a decision towards checking out
>>> shallow git repos.
>>Was this based on actual experience?  I find the git repositories to be
>>very fast to check out (and I am in Europe) in comparison to the
>>glacially slow process of checking out a hundred separate SVN
>>repositories one by one.
>>> it means that you can't use the git repository for anything
>>> useful.  Possibly also you can't use it for switching branches.
>>> That's true. So I usually create an alias for GetComponents to always
>>> use the --noshallow option like this:
>>> alias GC './GetComponents -a -v -p --noshallow'
>>> alias GCu './GetComponents -a -u -v -p --noshallow'
>>> where -v and -p options are not essential.
>>This seems to be a problem with a checkout of the release branch.  If
>>GetComponents is cloning the master branch with --depth 1, and then
>>trying to check out the release branch, and the release branch is not the
>>same as the master branch, I think this will fail.  It would probably
>>have worked when tested, because the release branch and the master branch
>>would have been the same at the time of the release.  With new enough
>>versions of Git, you can clone a specific branch on the command line
>>(-b/--branch option), so if you do a shallow clone with this option, it
>>should work.  But I would prefer ditching the shallow clones, unless
>>there is real-world evidence that a full clone contributes a significant
>>time to the checkout.
>>I still don't understand why I was able to perform the checkout with my
>>old version of Git.  Maybe something was tightened up in the newer
>>Bernard: does removing the --depth 1 option fix the problem?
>I'm afraid haven't been able to check your "--depth 1" fix yet; the
>machine in question is at home. I can check tonight.
>Users mailing list
>Users at einsteintoolkit.org

More information about the Users mailing list