Re: http protocol, cloning git.git, fails (too many open files)

From: Petr Baudis <pasky@suse.cz>
Date: Nov 14, 2005, 01:09 UTC
Message-ID: <20051114010940.GQ30496@pasky.or.cz>
In-Reply-To: <Pine.LNX.4.64.0511131625490.32662@x2.ybpnyarg>

Dear diary, on Mon, Nov 14, 2005 at 01:42:33AM CET, I got a letter where wa1ter@myrealbox.com said that...

Show 21 quoted lines

> 
> 
> On Sun, 13 Nov 2005, walt wrote:
> 
> > On Sat, 2005-11-12 at 15:21 -0800, Junio C Hamano wrote:
> > [...]
> > > However, one thing puzzles me.  I just tried to reproduce it by
> > > doing this:
> > >
> > > 	$ rm -fr git-http
> > >         $ ulimit -n 16
> > >         $ git clone http://www.kernel.org/pub/scm/git/git.git git-http
> > >
> > > and it did not fail on my Linux box...
> 
> > I've never seen it on Linux...
> 
> Aha!  I do indeed see it on linux with ulimit -n 64 but *only* when I
> do the clone with cg-clone.  When I use 'git clone' it works just fine.
> 
> So, what does cogito do differently that accounts for more open files?

Cogito uses the same logic and underlying GIT fetching commands for cloning as well as for fetching, while git-clone uses some custom logic for cloning ("dumb http clone"). (In fact, is there a point in carrying it further now that git-http-fetch got as smart as it got? You'll have less code, and more importantly see bugs in the fetchers otherwise only I see with Cogito. ;-)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.