Disable slocounts until algorithm can use server provided time stamps

In DataCollector::git::sloccount() it make use of timestamps in the commit metadata.

A timestamp on a git commit is just an arbitrary piece of metadata and it does not indicate when a commit was actually pushed into the product.

Here is a simple example which you can try out in any git repo:

echo 1 > file
git add file
GIT_COMMITTER_DATE=$(date -d '5 weeks ago') GIT_AUTHOR_DATE=$(date -d '5 weeks ago') git commit -m 'commit in past'
git log "--before=$(date -d '4 weeks ago')"

In the last step, it will show in the log the commit which was just created - even though it didn't exist 4 weeks ago! Therefore demonstrating that this method absolutely does not tell you what was HEAD of a particular branch 4 weeks ago.

In fact there is absolutely no way to robustly get this info from a git repo.

I understand this example may seem contrived, but this really will show up sometimes:

• someone pushes a large patch set for review to gerrit. It significantly increases the SLOC - for example, it adds a whole new Qt module.
• the reviewer(s) have some problems with the concept. They think the new module isn't appropriate to add to Qt. A big discussion goes on.
• two weeks later, it is finally decided that this is OK. The change is accepted and merged - with a two week old timestamp (depending on how gerrit is configured).
• suddenly, the metrics SLOC graph changes overnight - the value for two weeks ago jumps upwards! Of course, past values changing should be impossible.

In summary, this is more code in metrics which probably seems to be correct most of the time, but has never been validated and is actually subtly wrong. I suggest the SLOC graph be disabled and a task be created for fixing it.