From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Pitre Subject: Re: Cygwin can't handle huge packfiles? Date: Fri, 07 Apr 2006 10:11:38 -0400 (EDT) Message-ID: References: <7vhd55ls24.fsf@assigned-by-dhcp.cox.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 7BIT Cc: git@vger.kernel.org, Kees-Jan Dijkzeul , Linus Torvalds X-From: git-owner@vger.kernel.org Fri Apr 07 16:12:30 2006 Return-path: Envelope-to: gcvg-git@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FRrgs-0008Tm-0O for gcvg-git@gmane.org; Fri, 07 Apr 2006 16:11:58 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932329AbWDGOLt (ORCPT ); Fri, 7 Apr 2006 10:11:49 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932322AbWDGOLt (ORCPT ); Fri, 7 Apr 2006 10:11:49 -0400 Received: from relais.videotron.ca ([24.201.245.36]:2782 "EHLO relais.videotron.ca") by vger.kernel.org with ESMTP id S932329AbWDGOLs (ORCPT ); Fri, 7 Apr 2006 10:11:48 -0400 Received: from xanadu.home ([74.56.105.38]) by VL-MH-MR002.ip.videotron.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0IXC00HIKVFELAC0@VL-MH-MR002.ip.videotron.ca> for git@vger.kernel.org; Fri, 07 Apr 2006 10:11:39 -0400 (EDT) In-reply-to: <7vhd55ls24.fsf@assigned-by-dhcp.cox.net> X-X-Sender: nico@localhost.localdomain To: Junio C Hamano Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: On Fri, 7 Apr 2006, Junio C Hamano wrote: > Linus Torvalds writes: > > > On Mon, 3 Apr 2006, Linus Torvalds wrote: > >> > >> That said, I think git _does_ have problems with large pack-files. We have > >> some 32-bit issues etc > > > > I should clarify that. git _itself_ shouldn't have any 32-bit issues, but > > the packfile data structure does. The index has 32-bit offsets into > > individual pack-files. > > > > That's not hugely fundamental,... > > Linus _does_ understand what he means, but let me clarify and > outline a possible future direction. > [...] For the record, the delta code also has 32-bit limitations of its own presently. It cannot encode a delta against a buffer which is larger than 4GB. I however made sure the byte 0 could be used as a prefix for future encoding extensions, like 64-bit file offsets for example. Nicolas