Forums : Technical Issue Help
Dear Open Hub Users,
We’re excited to announce that we will be moving the Open Hub Forum to
https://community.synopsys.com/s/black-duck-open-hub.
Beginning immediately, users can head over,
register,
get technical help and discuss issue pertinent to the Open Hub. Registered users can also subscribe to Open Hub announcements here.
On May 1, 2020, we will be freezing https://www.openhub.net/forums and users will not be able to create new discussions. If you have any questions and concerns, please email us at
[email protected]
Counting lines of source code (Failed)
http://www.ohloh.net/projects/55/enlistments
http://anonsvn.jboss.org/repos/hibernate/core/trunk
Step 3 of 3: Counting lines of source code (Failed)
What to do with it?
I rescheduled this and it completed. Hibernate has a new analysis ready now.
Thanks for reporting the problem,
Andy
It seems that cgit has a similar problem:
http://www.ohloh.net/projects/8308/enlistments
Hi Lars,
I've rescheduled cgit. It should complete normally this time.
Thanks, but it seems to have failed again.
Could the problem be related to the fact that cgit uses git as a submodule?
Wow, absolutely. We do not support submodules yet. Unfortunately, the version of git we are running doesn't identify submodules, so our back end tools have no way to step around them. Yours is only the second repository we've found that uses submodules (MSysGit was the other).
It would probably be simple enough to write some code to ignore submodules (assuming that the new git has an easy way to identify or remove submodules from the log), but this will require some time for us to test for backward compatibility and roll out a new version of git on all of our servers.
Oh well, this should do the trick:
git ls-tree $REV | grep -ve '^160000 '
but you'll need git 1.5.2 or newer...
Or if you parse the output from 'git log -p', this pattern is what to look out for:
diff --git a/git b/git
index 86bab96..5587cac 160000
--- a/git
+++ b/git
@@ -1 +1 @@
-Subproject commit 86bab9615c3516d4ac7756ae3c1285d331b78f04
+Subproject commit 5587cac28be66acf5edc2a4b83b67c8cfffbc5e9
A simple ls-tree $REV -- $PATH | grep -e '^160000' could then be used to verify that the path actually is a submodule.
Actually, I just discovered an easier way: git-log -p --raw
This produces, for each rev, a list of changed paths (with mode-info, which enables you to identify submodules) followed by the diff proper.
Hi Lars,
OK, this looks doable, but non-trivial. We'll certainly have to implement it. It will probably be a while before I have a chance to work on it. Thanks for all the help... I might have some follow-up questions when I get there.
Thanks,
Robin
Hi
Just wondering: has there been any progress on the git submodule support?
larsh
No, sorry Lars, we have not had time to do this yet.
Ok, thanks for the quick reply (and please let me know if there's anything I can do to help out with this feature).
i see the same issue at tapestry as well...
See http://www.ohloh.net/projects/4017/enlistments
Hi Andreas,
I'm seeing something curious in the Tapestry enlistments. There are two enlistments:
http://svn.apache.org/repos/asf/tapestry
http://svn.apache.org/repos/asf/tapestry/tapestry4/trunk
One of these is entirely contained within the other, so the second enlistment is redundant. One or the other of these enlistments should be deleted. Do you know which we should keep?
We are unable to connect to to svn.apache.org right now, but I will check the status of these jobs again later today.