Forums : Feedback Forum

add support to ignore directories

My projects CVS repository contains code from other projects.
It is there to cut down dependency issues (additional
downloads needed to compile) and I would like ohloh to
ignore these parts. Maybe ohloh could look for files in the
repository (like web crawlers look for robots.txt) that
tell it to ignore certain directories?

best regards,

Randolf Ayam, where you get birails.

rschultz over 12 years ago

Hi Randolph,

We've been tossing this idea around for a while. Google code introduced the concept of using robots.txt in the repository to disallow specific directories. While we'll likely support that directive in the near future, we'd like to introduce more semantics as well, including: official project licenses, product vs test vs documentation directories and developer aliases. This would enable us to produce much more interesting analyses. However, at that point this directives file would be pretty different than a robots.txt. I guess we could call it ohloh.txt but we'd be happy to call it something more generic ( info.txt?).


  • would you be willing to add/maintain such a file in your repository?
  • any naming preferences?


Jason Allen over 12 years ago

Hello Jason,

thank you for the feedback.
I am glad to hear that you will probably support robots.txt in the future.
As for the other, more ohloh or analysis specific, information, I would
prefer to not have and maintain this information in the repository but
rather specify those things when managing enlistments.
This is, because one wants to specify it in one file per project, but
can not manage such a file outside of any modules on SourceForge CVS.
If you decide to get this information solely from the repository,
a generic file name like would be preferable.

best regards,

Randolf, Ayam, where import means NURBS.

rschultz over 12 years ago

Thanks for the input,


Jason Allen over 12 years ago

Any update on this support?
My web project relies on external libraries that are included within the source (such as Prototype, Scriptaculous) which are highly skewing the statistics.


Danny Allen over 8 years ago

This sounds useful to other projects as well. We'll look into it and keep everyone posted.

Abhay Mujumdar over 8 years ago

Hi everyone,

(posting here as this seems to be the original thread re this issue.)

As we start working on improving Ohloh, our top priority is to improve the quality of Ohloh’s data. This obviously includes the ability to choose to ignore certain directories that do not make sense to be analyzed as part of a project’s codebase.

We wanted to get your feedback about our proposed solution.

Short Term Proposal

For the short term, we want to enable both the following approaches:
1. Project owners can specify a .ohloh file in their root directory of their repository, telling Ohloh which directories to ignore
1. Users can specify which directories to ignore through the UI on the Enlistment page of the project. The same moderation/permissions will apply as all other parts of Ohloh, meaning managers of the project can restrict access if needed.

.ohloh file

We’ve seen feedback on the forums for support for a .ohloh file (similar to a robot.txt file) that specifies which directories to ignore, like test cases, documentation, 3rd party libraries, and so forth.

For example, the contents of anyFileName.ohloh would simply contain:

Disallow: /MyDirectoryName

Ignore UI on Enlistment page

For project owners who do not wish to include a .ohloh file in their repository or might not be aware their project is being included into Ohloh’s network, we’ll provide a very simple “Ignore” textbox for each enlistment on the Enlistment page of a project.

For example, consider Turbogears, which is written in Python but Ohloh says it is mostly written in Javascript. On the Enlistment page, visualize an “Ignore” link under each Enlistment “Delete” link. The manager for the Ohloh project will be able to place restrictions on this functionality, just like in many other places in Ohloh. The Ignore link will pop up a text box (or some other common UI mechanism), which allows the user to specify which directories to ignore, just as if they were creating a .ohloh file for their local repository.

Long term

As a waterfall->agile convert, I’m a big believer in getting simple features out of the door as quickly as possible. We realize that more UI support, like a tree view of the current enlistment to pick and choose what directories to ignore, would be a more ideal user experience, and this is something we’ll want to get feedback on moving forward.

In the short term, I feel that enabling these two initial items (.ohloh file and Ignore textbox) will help address these data quality issues, while providing a good user experience for project owners and end users alike.

Let us know your thoughts!

Sara Ford over 8 years ago

Just get something working fast.

The .ohloh file approach sounds easy to implement from a technical standpoint, and emulates a standard most developers already know.

You have our vote for this approach.

Carl Roett over 8 years ago

Sara: The .ohloh file sounds very nice. Just one additional feature to make it really useful: Allow uploading the .ohloh file through the Ohloh web interface.

- The author doesn't like to add anything to their source code which is not (technically) necessary.
- The author doesn't care about Ohloh at all (maybe doesn't even know it) but an interested user wants to ensure that code analysis is shown correctly.

As an registered Ohloh user I want to upload a .ohloh file to exclude some directory from code analysis so that Ohloh can show me correct statistics for projects where the author does not want to add an .ohloh file.

Felix Schwarz over 8 years ago

@Felix Thanks for the feedback. You're absolutely right that we need to handle the case where the .ohloh file is separate from the source code. We're currently figuring out how to best approach this issue, and I'll definitely include your suggestion in our discussions.


Sara Ford over 8 years ago


I like the idea of moving towards a file to describe various things. Even better if it's an open standard to increase the desire for projects to generate one.

Some ideas:

"PAD is the Portable Application Description, and it helps authors provide product descriptions and specifications to online sources in a standard way, using a standard data format that will allow webmasters and program librarians to automate program listings. PAD saves time for both shareware authors and webmasters."

Please also see the "Open Software Description Format (OSD)"

Best regards,

M ;-)

Marc Laporte over 8 years ago

A .ohloh file that follows robots.txt syntax is enough, and open enough, for this use, and OSD is overly complex.

Jack Repenning over 8 years ago

I like that idea in general. Don't have any specific suggestions but looking forward to the result :) thumbs up

Marenz over 8 years ago

Whenever this feature is done, feel free to test with the Midgard Create project. I've added the following .ohloh file there:

Henri Bergius over 8 years ago

@bergie Thanks! We'll definitely contact you when the time comes for us to start testing on real-world projects.

Sara Ford over 8 years ago

I'm very interested in this feature as well. On Google Code projects we keep the JavaDoc in Subversion which causes ohloh to produce totally odd numbers.

Is there a way to "subscribe" to this thread in order to get informed when you start testing the feature?

Richard Eckart ... over 8 years ago

@rec Go to My Account (shown in navigation bar when logged in) - Notifications, and select Email me: When my forum topics are updated. Cheers!

Sara Ford over 8 years ago

@Sara: Thanks :) Looks like I already had that activated as I got your reply per mail. Now I'm looking forward to the exclusion feature.

Richard Eckart ... over 8 years ago

your .ohloh file isn't working for me

I put it on the root directory but when you scan the repo again, it doesn't exclude what I want it to

Pyritie over 8 years ago

@Pyritie: This might be because the feature is not implemented yet ;-)

Felix Schwarz over 8 years ago

...oh :D

Pyritie over 8 years ago

A suggestion: rather than using .ohloh, consider using .ohlohignore and having it only include "ignore" entries. People already have a strong understanding of .gitignore and the equivalents for other version control systems, and .ohlohignore would fit right in. In the event you want other configuration in the future, you could always add a .ohlohrc or .ohloh file at that point.

Josh Triplett over 8 years ago

Hi all,

We deployed our latest updates to the Ohloh site yesterday, which includes a way to specify which files and/or directories Ohloh should ignore!

On the Enlistments page for a project, you’ll see the “Choose files to ignore” link for each enlistment.

This will bring you to the Ignore Files page, where you can specify which files and directories to ignore.

For example, to ignore specific directories, you can use

 # Some commonly excluded paths 
 Disallow: lib/ 
 Disallow: tools/

And for specific files, you can use

 # Some random files from this repository 
 Disallow: 7zSD.sfx

We have more examples and tips located on the Ignore Files page.

Choosing which files to ignore must be done with the Ohloh web interface. As I mentioned earlier, we were looking into supporting a robots.txt file in the source code itself. But, we felt that this behavior wouldn't be as popular as having a simple web entry, so we went with web-based solution.

If you have any reasons why you would want to use a .ohloh file over the web interface, please let us know.

You can read the full blog post of all the features in this update at

Please give it a try, and let me know your thoughts.

Sara Ford over 8 years ago

awesome, I'll give it a try

Pyritie over 8 years ago

Thanks a lot, Sara. Works very well for me :-)

Felix Schwarz over 8 years ago

Post a Response