Re: git pull aborts in 50% of cases

From: Junio C Hamano <junkio@cox.net>
Date: Dec 3, 2005, 02:26 UTC
Message-ID: <7vu0dq29wg.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <Pine.LNX.4.63.0512030316520.19086@wbgn013.biozentrum.uni-wuerzburg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

Show 7 quoted lines

>> 0.99.9k is clearly bad.
>
> Huh? It could be slower, and it could therefore hit the maximum client 
> count faster, but it should not be bad.
>
> All changes to pull were done in a manner so as to be backward compatible. 
> In both ways.

I do not think the fetch-pack common computation changes is involved in this problem at all.

What is suspect is the repository validity check code, specifically (quoting from diff between 0.99.9j and 0.99.9k daemon.c::path_ok() function):

+               /* The validation is done on the paths after enter_repo
+                * canonicalization, so whitelist should be written in
+                * terms of real pathnames (i.e. after ~user is expanded
+                * and symlinks resolved).
+                */

I suspect (but have not heard back from HPA to confirm) that kernel.org runs git-daemon with /pub/scm as the whitelist, but there is a symbolic link (or bind mount?) involved, and the real path checked based on getcwd() return value is somewhere else.