Hi all, I'm updating some KDE projects that got moved from SVN to git, but didn't get their ohloh enlistments updated. Unfortunately they're proving pretty hard to find. I'd like a list of ohloh ... [More] projects that have failing enlistments with kde.org in their URL. Could some ohloh admin make such a query and let me know the list? In addition, maybe even more important, I'd like to know projects with enlistments whose URLs start with svn://anonsvn.kde.org/home/kde/trunk/KDE/kdeutils, whether they're failing or not, since kdeutils is going to move to git real soon. Thanks in advance. [Less]

I found a way to fix the repo, stay tuned. EDIT: wait, it looks like ohloh was already working by now?! Oh well, too late. Repository already reset and I'm uploading the fixed version.

Thanks for the spam.

(I searched the forum for similar threads, but only found requests for ignoring files; which btw I'm also interested in) In the project 'synecdoche', Ohloh thinks I wrote a few hundred thousand ... [More] lines. Actually, I just fixed line endings on the whole repository. I probably wrote less than a hundred lines for the (quite new) project so far. There should be a way to mark individual commits so that ohloh doesn't count them, neither to the project (like in the re-write cost estimation) nor to the contributor. The most common case for this is the initial code checkin. Even more important if that initial code isn't just code written by the project before they started using a VCS; but code forked from another project. It shouldn't show as written by a single person (in a day :P). Here is the whole list of commits I'd mark as ignored for synecdoche: r2: thousand files added, hundred thousand lines. This was the actual initial commit. Ohloh seems to ignore r1, but that was just the structure (trunk, branches, tags). The actual code (forked from another project) was committed in this rev. Ohloh thinks user 'didactylos' wrote a hundred thousand lines in a day :) In addition, this initial commit had DOS line endings (CRLF) in all the text files, which made Unix builds break (no /bin/sh^M found). I fixed it later; cluttering my language experience even more (see below). r4: added 25 automake files that were missed in r2. These are also from the forked project. r5: 34 files (4739 lines) modified. I fixed line endings in shell scripts, which were breaking the build. Ohloh now thinks I wrote four thousand lines of shell script and that that is the language I know the most. r8 had more line ending fixes on the build system, 460 lines. Yet more on r9, 4900 lines (a single file!). r25: the very worst. I fixed the newlines on every single text file in the repository. 887 files modified, 101514 lines modified. I don't want all that attributed to me. r26: 1569 more CRLFs converted to LFs. And everything is fine now, I don't think there will be any other massive automated change to do, just real code to write :) But that real code, real work, will show as minor stuff compared to all the newlines I changed using a script. (Oh actually... I may do a tab -> four spaces conversion on every file some day; but I'll wait for this feature to be added on Ohloh) [Less]