I get the following error when I run
git submodule update --init
on the 2.8 branch
Submodule 'release' () registered for path 'release'
fatal: Needed a single revision
Unable to find current revision in submodule path 'release'
Looks like the submodule needs to be relinked
I noticed that the nightly builds are also not working anymore - this may be
part of the problem
Thank you
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/2-8-submodule-relink-release-tp5013319.html
Sent from the GeoNetwork developer mailing list archive at Nabble.com.
FYI: I'm also having some issues performing a basic clone operation.
$git clone --recursive
https://github.com/geonetwork/core-geonetwork.git geonetwork
Cloning into 'geonetwork'...
remote: Counting objects: 67353, done.
remote: Compressing objects: 100% (22615/22615), done.
error: RPC failed; result=56, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
Looking at the status at github - it seems like github is having some
issues.
https://status.github.com/
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/2-8-submodule-relink-release-tp5013319p5013323.html
Sent from the GeoNetwork developer mailing list archive at Nabble.com.
As a matter of fact I’m not 100% sure it was the best decision to use submodules in our project. Doesn’t the added complexity outweigh any practical benefits we have ?
Of course I may be totally wrong here. But we’re still quite new to Git, as GeoNetwork community, and we could adjust things still for the better, if yall agree.
What are your opinions, list ?
Just my 2¢
Kind regards
Heikki Doeleman
On Thu, Nov 1, 2012 at 3:27 PM, ianwallen <ianwallen@anonymised.com> wrote:
FYI: I’m also having some issues performing a basic clone operation.
$git clone --recursive
https://github.com/geonetwork/core-geonetwork.git geonetwork
Cloning into ‘geonetwork’…
remote: Counting objects: 67353, done.
remote: Compressing objects: 100% (22615/22615), done.
error: RPC failed; result=56, HTTP code = 200
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
Looking at the status at github - it seems like github is having some
issues.
https://status.github.com/ <https://status.github.com/>
–
View this message in context: http://osgeo-org.1560.n6.nabble.com/2-8-submodule-relink-release-tp5013319p5013323.html
Sent from the GeoNetwork developer mailing list archive at Nabble.com.
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at http://sourceforge.net/projects/geonetwork
I have to concur with Heikki. I am still just in the learning stages of Git,
but the submodules are what gives me the most headaches. I thought it was
just me, but when I ask others with more Git experence about the troubles I
am having with Git, they often question the use of submodules. My feeling is
if submodules are unnecessary and complicate the usage, perhaps they should
not used.
But maybe I am overlooking some advantages?
Cheers,
Byron
--
View this message in context: http://osgeo-org.1560.n6.nabble.com/2-8-submodule-relink-release-tp5013319p5013411.html
Sent from the GeoNetwork developer mailing list archive at Nabble.com.
There are a couple of reason for the submodules.
- All history for then entire repository is cloned everytime. That includes all jars, images, etc… that have every been committed. I have all the modules that have big binaries in submodules so we can kill them/clean then if we want to to keep the downloads of the main repository faster, smaller.
- The submodules allows us to give people access to certain portions of the repository but not others. For example docs.
- Third party projects that don’t need all submodules can remove the link and suddenly the clone is much faster. For example Geocat.ch doesn’t use geoserver, docs, installer or Gast and it clones much faster than the full geonetwork
Submodules are more complicated that svn:externals because they lock to a particular version thus they take time to adjust.
Consider the case where we no longer need maven_repo module.
Submodules: We remove the submodule link and suddenly the clone of master is much faster
No submodules: There is no benefit because the repository is just as large as before removing the maven_repo module
We could reduce the number of submodules. For example only keep webspecs and maven_repo as submodules. We could modify Geoserver to have its binaries in maven_repo.
Jesse