[moving back to the list after two off-list mails]
Hi Ian.
OK, I've tried the bare git commands you mention. Here are my results:
-------------------------------
humperdinck:~ prince$ git clone --depth 1 git://carpetcode.org/McLachlan Cloning into 'McLachlan'... remote: Counting objects: 961, done. remote: Compressing objects: 100% (627/627), done. remote: Total 961 (delta 772), reused 428 (delta 327) Receiving objects: 100% (961/961), 897.79 KiB | 397 KiB/s, done. Resolving deltas: 100% (772/772), done.
humperdinck:~ prince$ cd McLachlan/
humperdinck:McLachlan prince$ git checkout --track -b ET_2011_10 origin/ET_2011_10 fatal: git checkout: updating paths is incompatible with switching branches. Did you intend to checkout 'origin/ET_2011_10' which can not be resolved as commit?
humperdinck:McLachlan prince$ git --version git version 1.7.10.2
-------------------------------
I note that (a) there are far fewer "objects" in my git checkout (perhaps this is normal?) than in yours -- 978 vs 3878; (b) my git version is 1.7.10.2, rather than the 1.7.5.4. This is the current result of an up-to-date MacPorts install of git-core.
Bernard
On 5/23/12 7:56 AM, "Ian Hinder" ian.hinder@aei.mpg.de wrote:
On 23 May 2012, at 13:25, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] wrote:
Hi Ian.
Yes, I should have explained that this was an additional checkout after most of ETK was already checked out (hence the number 12 instead of 175 or so). But the original checkout was also Maxwell, and was performed only a day or two earlier, with the same GetComponents and thornlist.
I just moved that whole Cactus aside and redid from scratch. Identical failure (but this time saying 175). Almost everything checks out fine; just not McLachlan and KrancNumericalTools, and GetComponents itself, apparently (?).
I've redone the checkout (again after the main checkout) with the "--verbose" option. Result after main text. The option "--verbose 2" fails, so presumably the correct syntax is slightly different; I didn't hang around to check.
BTW, I don't really think the issue has anything to do with my OS X version, though I suppose my MacPorts git might have some funny settings.
Hi Bernard,
Can we move this back to the list? Others might have suggestions and will benefit in future from the discussion. I have done this:
MacBook-2:temp $ git clone --depth 1 git://carpetcode.org/McLachlan Cloning into McLachlan... remote: Counting objects: 3878, done. remote: Compressing objects: 100% (2222/2222), done. remote: Total 3878 (delta 3229), reused 2050 (delta 1638) Receiving objects: 100% (3878/3878), 2.38 MiB | 838 KiB/s, done. Resolving deltas: 100% (3229/3229), done. MacBook-2:temp $ cd McLachlan/ MacBook-2:McLachlan (master) $ git checkout --track -b ET_2011_10 origin/ET_2011_10 Branch ET_2011_10 set up to track remote branch ET_2011_10 from origin. Switched to a new branch 'ET_2011_10' MacBook-2:McLachlan (ET_2011_10) $ git --version git version 1.7.5.4
Those are the commands that GetComponents claims to be using. Can you try these commands on their own and see what happens? It might be something to do with old versions of Git, or maybe GetComponents is doing something different than the commands it outputs.
Have a look at http://stackoverflow.com/questions/499316/git-plugin-for-hudson-checkout-p roblem, and other google hits for the checkout error message. It's looking like it might be a problem with an old version of git.
-- Ian Hinder http://numrel.aei.mpg.de/people/hinder
On 23 May 2012, at 14:19, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] wrote:
[moving back to the list after two off-list mails]
Hi Ian.
OK, I've tried the bare git commands you mention. Here are my results:
humperdinck:~ prince$ git clone --depth 1 git://carpetcode.org/McLachlan Cloning into 'McLachlan'... remote: Counting objects: 961, done. remote: Compressing objects: 100% (627/627), done. remote: Total 961 (delta 772), reused 428 (delta 327) Receiving objects: 100% (961/961), 897.79 KiB | 397 KiB/s, done. Resolving deltas: 100% (772/772), done.
humperdinck:~ prince$ cd McLachlan/
humperdinck:McLachlan prince$ git checkout --track -b ET_2011_10 origin/ET_2011_10 fatal: git checkout: updating paths is incompatible with switching branches. Did you intend to checkout 'origin/ET_2011_10' which can not be resolved as commit?
humperdinck:McLachlan prince$ git --version git version 1.7.10.2
I note that (a) there are far fewer "objects" in my git checkout (perhaps this is normal?) than in yours -- 978 vs 3878; (b) my git version is 1.7.10.2, rather than the 1.7.5.4. This is the current result of an up-to-date MacPorts install of git-core.
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; it means that you can't use the git repository for anything particularly useful. Possibly also you can't use it for switching branches.
The documentation says:
--depth <depth> Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches.
Can you try it without the --depth 1 option and see if that fixes it?
Bernard
On 5/23/12 7:56 AM, "Ian Hinder" ian.hinder@aei.mpg.de wrote:
On 23 May 2012, at 13:25, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] wrote:
Hi Ian.
Yes, I should have explained that this was an additional checkout after most of ETK was already checked out (hence the number 12 instead of 175 or so). But the original checkout was also Maxwell, and was performed only a day or two earlier, with the same GetComponents and thornlist.
I just moved that whole Cactus aside and redid from scratch. Identical failure (but this time saying 175). Almost everything checks out fine; just not McLachlan and KrancNumericalTools, and GetComponents itself, apparently (?).
I've redone the checkout (again after the main checkout) with the "--verbose" option. Result after main text. The option "--verbose 2" fails, so presumably the correct syntax is slightly different; I didn't hang around to check.
BTW, I don't really think the issue has anything to do with my OS X version, though I suppose my MacPorts git might have some funny settings.
Hi Bernard,
Can we move this back to the list? Others might have suggestions and will benefit in future from the discussion. I have done this:
MacBook-2:temp $ git clone --depth 1 git://carpetcode.org/McLachlan Cloning into McLachlan... remote: Counting objects: 3878, done. remote: Compressing objects: 100% (2222/2222), done. remote: Total 3878 (delta 3229), reused 2050 (delta 1638) Receiving objects: 100% (3878/3878), 2.38 MiB | 838 KiB/s, done. Resolving deltas: 100% (3229/3229), done. MacBook-2:temp $ cd McLachlan/ MacBook-2:McLachlan (master) $ git checkout --track -b ET_2011_10 origin/ET_2011_10 Branch ET_2011_10 set up to track remote branch ET_2011_10 from origin. Switched to a new branch 'ET_2011_10' MacBook-2:McLachlan (ET_2011_10) $ git --version git version 1.7.5.4
Those are the commands that GetComponents claims to be using. Can you try these commands on their own and see what happens? It might be something to do with old versions of Git, or maybe GetComponents is doing something different than the commands it outputs.
Have a look at http://stackoverflow.com/questions/499316/git-plugin-for-hudson-checkout-p roblem, and other google hits for the checkout error message. It's looking like it might be a problem with an old version of git.
-- Ian Hinder http://numrel.aei.mpg.de/people/hinder
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.
it means that you can't use the git repository for anything particularly 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.
Cheers, Bruno.
The documentation says:
--depth<depth> Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches.
Can you try it without the --depth 1 option and see if that fixes it?
Bernard
On 5/23/12 7:56 AM, "Ian Hinder"ian.hinder@aei.mpg.de wrote:
On 23 May 2012, at 13:25, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] wrote:
Hi Ian.
Yes, I should have explained that this was an additional checkout after most of ETK was already checked out (hence the number 12 instead of 175 or so). But the original checkout was also Maxwell, and was performed only a day or two earlier, with the same GetComponents and thornlist.
I just moved that whole Cactus aside and redid from scratch. Identical failure (but this time saying 175). Almost everything checks out fine; just not McLachlan and KrancNumericalTools, and GetComponents itself, apparently (?).
I've redone the checkout (again after the main checkout) with the "--verbose" option. Result after main text. The option "--verbose 2" fails, so presumably the correct syntax is slightly different; I didn't hang around to check.
BTW, I don't really think the issue has anything to do with my OS X version, though I suppose my MacPorts git might have some funny settings.
Hi Bernard,
Can we move this back to the list? Others might have suggestions and will benefit in future from the discussion. I have done this:
MacBook-2:temp $ git clone --depth 1 git://carpetcode.org/McLachlan Cloning into McLachlan... remote: Counting objects: 3878, done. remote: Compressing objects: 100% (2222/2222), done. remote: Total 3878 (delta 3229), reused 2050 (delta 1638) Receiving objects: 100% (3878/3878), 2.38 MiB | 838 KiB/s, done. Resolving deltas: 100% (3229/3229), done. MacBook-2:temp $ cd McLachlan/ MacBook-2:McLachlan (master) $ git checkout --track -b ET_2011_10 origin/ET_2011_10 Branch ET_2011_10 set up to track remote branch ET_2011_10 from origin. Switched to a new branch 'ET_2011_10' MacBook-2:McLachlan (ET_2011_10) $ git --version git version 1.7.5.4
Those are the commands that GetComponents claims to be using. Can you try these commands on their own and see what happens? It might be something to do with old versions of Git, or maybe GetComponents is doing something different than the commands it outputs.
Have a look at http://stackoverflow.com/questions/499316/git-plugin-for-hudson-checkout-p roblem, and other google hits for the checkout error message. It's looking like it might be a problem with an old version of git.
-- Ian Hinder http://numrel.aei.mpg.de/people/hinder
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 particularly 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 version.
Bernard: does removing the --depth 1 option fix the problem?
Cheers, Bruno.
The documentation says:
--depth<depth> Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches.
Can you try it without the --depth 1 option and see if that fixes it?
Bernard
On 5/23/12 7:56 AM, "Ian Hinder"ian.hinder@aei.mpg.de wrote:
On 23 May 2012, at 13:25, Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] wrote:
Hi Ian.
Yes, I should have explained that this was an additional checkout after most of ETK was already checked out (hence the number 12 instead of 175 or so). But the original checkout was also Maxwell, and was performed only a day or two earlier, with the same GetComponents and thornlist.
I just moved that whole Cactus aside and redid from scratch. Identical failure (but this time saying 175). Almost everything checks out fine; just not McLachlan and KrancNumericalTools, and GetComponents itself, apparently (?).
I've redone the checkout (again after the main checkout) with the "--verbose" option. Result after main text. The option "--verbose 2" fails, so presumably the correct syntax is slightly different; I didn't hang around to check.
BTW, I don't really think the issue has anything to do with my OS X version, though I suppose my MacPorts git might have some funny settings.
Hi Bernard,
Can we move this back to the list? Others might have suggestions and will benefit in future from the discussion. I have done this:
MacBook-2:temp $ git clone --depth 1 git://carpetcode.org/McLachlan Cloning into McLachlan... remote: Counting objects: 3878, done. remote: Compressing objects: 100% (2222/2222), done. remote: Total 3878 (delta 3229), reused 2050 (delta 1638) Receiving objects: 100% (3878/3878), 2.38 MiB | 838 KiB/s, done. Resolving deltas: 100% (3229/3229), done. MacBook-2:temp $ cd McLachlan/ MacBook-2:McLachlan (master) $ git checkout --track -b ET_2011_10 origin/ET_2011_10 Branch ET_2011_10 set up to track remote branch ET_2011_10 from origin. Switched to a new branch 'ET_2011_10' MacBook-2:McLachlan (ET_2011_10) $ git --version git version 1.7.5.4
Those are the commands that GetComponents claims to be using. Can you try these commands on their own and see what happens? It might be something to do with old versions of Git, or maybe GetComponents is doing something different than the commands it outputs.
Have a look at http://stackoverflow.com/questions/499316/git-plugin-for-hudson-checkout-p roblem, and other google hits for the checkout error message. It's looking like it might be a problem with an old version of git.
-- Ian Hinder http://numrel.aei.mpg.de/people/hinder
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
On Wed, May 23, 2012 at 12:48 PM, Ian Hinder ian.hinder@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.
If I recall correctly, this was more of a safety decision that a benchmarked decision. The reasoning went something like "with an anonymous checkout you can't commit anyway, so a shallow checkout suffices". We were not aware of any negative effect of shallow clones.
-erik
On 23 May 2012, at 20:10, Erik Schnetter wrote:
On Wed, May 23, 2012 at 12:48 PM, Ian Hinder ian.hinder@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.
If I recall correctly, this was more of a safety decision that a benchmarked decision.
OK, in that case I think it is unnecessary, and should be reverted. I don't like shallow clones.
The reasoning went something like "with an anonymous checkout you can't commit anyway, so a shallow checkout suffices". We were not aware of any negative effect of shallow clones.
With an anonymous checkout, you can commit and push. You have to add the correct URL to push to: git push <url>, but you can still push. This is a lot easier than checking out your Cactus tree again in non-anonymous mode.
Hello all,
With an anonymous checkout, you can commit and push. You have to add the correct URL to push to: git push <url>, but you can still push. This is a lot easier than checking out your Cactus tree again in non-anonymous mode.
Also a number of users and maintainers may not be able to check out the whole tree non-anonymously since they don't have write permissions to all of the git/hg repositories (only Carpet is affected I think). Currently that does not seem to include me though :-)
There was at one point a discussion about making "-a" in GetComponents the default (assuming there are more users with read only access than developers with read/write access) at http://lists.einsteintoolkit.org/pipermail/users/2011-December/001687.html
As far as I can see no clear decision whether to make "-a" the default was reached. At that time the feeling seems to have been that the interactive questioning by GetComponents was sufficient (but that it was broken at that time).
Yours, Roland
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 24 May 2012, at 18:04, Roland Haas wrote:
Hello all,
With an anonymous checkout, you can commit and push. You have to add the correct URL to push to: git push <url>, but you can still push. This is a lot easier than checking out your Cactus tree again in non-anonymous mode.
Also a number of users and maintainers may not be able to check out the whole tree non-anonymously since they don't have write permissions to all of the git/hg repositories (only Carpet is affected I think). Currently that does not seem to include me though :-)
There was at one point a discussion about making "-a" in GetComponents the default (assuming there are more users with read only access than developers with read/write access) at http://lists.einsteintoolkit.org/pipermail/users/2011-December/001687.html
As far as I can see no clear decision whether to make "-a" the default was reached. At that time the feeling seems to have been that the interactive questioning by GetComponents was sufficient (but that it was broken at that time).
I would prefer that "-a" was the default. We always use it in tutorials anyway, and options should be for exceptional cases.
We could also make it easier for people to commit from an anonymous checkout. In Git, the clone operation creates a remote called "origin" which points to the server that was cloned from. We could make GetComponents create an additional remote called "origin-rw" which used the AUTH_URL, and could be pushed to if you had the correct permissions. You could then do "git push origin-rw". How do you commit to a different repository in SVN? Do you need to use "svn switch", or is there an easier way? If we add instructions to how to commit from an anonymous checkout, I think we could make anonymous the default.
- -- Ian Hinder http://numrel.aei.mpg.de/people/hinder
Hi,
On Thu, May 24, 2012 at 06:44:05PM +0200, Ian Hinder wrote:
We could also make it easier for people to commit from an anonymous checkout.
How do you commit to a different repository in SVN? Do you need to use "svn switch", or is there an easier way?
It depends. When the checkout was done using http you have to 'switch', as authenticated http is disabled on most svn servers (for good reason).
You can however also checkout anonymously using https. Then there would be no problem committing from such a checkout. Unlike git/hg you can use the same mechanism because authentication is only performed for write operations (at least this is how it is setup on most systems).
However, there is one drawback: https is simply slower than http, the encryption has it's price. The question is whether we are willing to pay it - both on server side (higher load) and on client side (longer time for ET checkout). Also, possible certificate problems would affect a larger number of people.
Frank
On 24 May 2012, at 18:44, Ian Hinder wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 24 May 2012, at 18:04, Roland Haas wrote:
Hello all,
With an anonymous checkout, you can commit and push. You have to add the correct URL to push to: git push <url>, but you can still push. This is a lot easier than checking out your Cactus tree again in non-anonymous mode.
Also a number of users and maintainers may not be able to check out the whole tree non-anonymously since they don't have write permissions to all of the git/hg repositories (only Carpet is affected I think). Currently that does not seem to include me though :-)
There was at one point a discussion about making "-a" in GetComponents the default (assuming there are more users with read only access than developers with read/write access) at http://lists.einsteintoolkit.org/pipermail/users/2011-December/001687.html
As far as I can see no clear decision whether to make "-a" the default was reached. At that time the feeling seems to have been that the interactive questioning by GetComponents was sufficient (but that it was broken at that time).
I would prefer that "-a" was the default. We always use it in tutorials anyway, and options should be for exceptional cases.
We could also make it easier for people to commit from an anonymous checkout. In Git, the clone operation creates a remote called "origin" which points to the server that was cloned from. We could make GetComponents create an additional remote called "origin-rw" which used the AUTH_URL, and could be pushed to if you had the correct permissions. You could then do "git push origin-rw". How do you commit to a different repository in SVN? Do you need to use "svn switch", or is there an easier way? If we add instructions to how to commit from an anonymous checkout, I think we could make anonymous the default.
It looks like git has a config option for specifying both the "url" and the "pushurl" for a remote. I have not tried this, but I think we could set it up so that pulls always come from the anonymous URL and pushes go to the authenticated URL with
git remote set-url --push origin carpetgit@carpetcode.org:McLachlan
This adds a "push URL" to the "origin" remote which is used when pushing only. This would go in GetComponents in the "handle_git" function around line 1382. So for Git, we don't need a distinction between anonymous and authenticated checkouts. All checkouts can be anonymous, and people with commit access can just do "git push" when they need to.
Maybe the other version control systems have a similar feature.
Hi Ian.
On 5/23/12 12:48 PM, "Ian Hinder" ian.hinder@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 particularly 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 version.
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.
Bernard
Replying to myself here.
I noticed that my local Snow Leopard machine's git version (1.7.10.1) 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,
Bernard
On 5/23/12 2:16 PM, "Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY]" bernard.j.kelly@nasa.gov wrote:
Hi Ian.
On 5/23/12 12:48 PM, "Ian Hinder" ian.hinder@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 particularly 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 version.
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.
Bernard
Users mailing list Users@einsteintoolkit.org http://lists.einsteintoolkit.org/mailman/listinfo/users
users@lists.einsteintoolkit.org
-
Bruno C. Mundim -
Erik Schnetter -
Frank Loeffler -
Ian Hinder -
Kelly, Bernard J. (GSFC-660.0)[UNIVERSITY OF MARYLAND BALTIMORE COUNTY] -
Roland Haas