Comment 7 for bug 1012037

Couple of updates.

This kernel tree: http://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq.git ( http://git.kernel.org/?p=linux/kernel/git/davej/cpufreq.git;a=summary ) does not have a "real" HEAD ref, and it doesn't even have a master branch, it has two remote branches: "next" and "fixes", and they both didn't see a commit in 3 months.
We might consider:
- removing it in some way, but it might pops up again if there are old patches that went in there
- create a workaround for this: just skip it; or after cloning it do a "git checkout next" in order to swith to that branch, hoping the patches we have are there, but this means that a "git pull origin HEAD" (as it is written in the code for the next update command) will always not work (BTW that command will work also if written as "git pull origin" since HEAD is just a reference).

The problem we have with the timeout on kernel trees, looks like lies in the output from git and the subprocess.Popen function. For unknown reasons to me, git output of "git clone" all goes to stderr (I thought it was stdout). Non-suppressing that, the clone operation works (in a couple of cases I had to increment the max timeout, because I really reached that timeout probably due to a slower connection). I tried also passing "-q" (for quite) to "git clone", increasing the bufsize, and redirecting stderr to /dev/null on the command line, but all ot these didn't work. Using the GIT protocol instead of HTTP, the timeouts do no happen anymore. The "pull" operations do not seem to be affected by this problem.