From mboxrd@z Thu Jan 1 00:00:00 1970 From: Liu Yubao Subject: Re: two questions about the format of loose object Date: Mon, 01 Dec 2008 17:28:53 +0800 Message-ID: <4933AE55.2090007@gmail.com> References: <493399B7.5000505@gmail.com> <7voczws3np.fsf@gitster.siamese.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: git list To: Junio C Hamano X-From: git-owner@vger.kernel.org Mon Dec 01 10:30:24 2008 Return-path: Envelope-to: gcvg-git-2@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1L756m-0003tJ-3X for gcvg-git-2@gmane.org; Mon, 01 Dec 2008 10:30:24 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750920AbYLAJ3H (ORCPT ); Mon, 1 Dec 2008 04:29:07 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750924AbYLAJ3G (ORCPT ); Mon, 1 Dec 2008 04:29:06 -0500 Received: from ti-out-0910.google.com ([209.85.142.184]:28827 "EHLO ti-out-0910.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750876AbYLAJ3D (ORCPT ); Mon, 1 Dec 2008 04:29:03 -0500 Received: by ti-out-0910.google.com with SMTP id b6so1573393tic.23 for ; Mon, 01 Dec 2008 01:29:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=G2Hbndh9Upm0bDPxNO1UoBTgkdktaLgmNubncFlRtco=; b=kgmnlGxbV51eYi/t/LoT7tptnds2esjvaaS/Pb8AB+R+IoortbCZim9Ck/NgJceEPU CvnWK61OktLAmzsx/vb5Sy8ijesgCoQW3Qp2vOZPRyZ2Q0R62EDBI6YWrUQrKQF3aF66 quGDEmHNJ1+OSjdtzOEYa9x7uPybx2iOCQvWk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=I6FRDBQvWDBnhpiQk4CNnOOATXbpk1cPcP6y6tsxmXrXRidMLsU6jZkK7S4s0ru904 s9XqxTh2V8CVjB/XtxgWUli+AiC0XJ6sq9j0JJ1LOiUXo6ghHeonjigAlSyV6mpzEc/J QzCVz8k4b/xPQnvr1wOMpVSPtwlRdNsF8niXk= Received: by 10.110.28.15 with SMTP id b15mr7650404tib.0.1228123741858; Mon, 01 Dec 2008 01:29:01 -0800 (PST) Received: from ?10.64.1.142? ([211.157.41.194]) by mx.google.com with ESMTPS id 22sm280491tim.7.2008.12.01.01.28.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 01 Dec 2008 01:29:00 -0800 (PST) User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) In-Reply-To: <7voczws3np.fsf@gitster.siamese.dyndns.org> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Junio C Hamano wrote: > Liu Yubao writes: > > > A hint for understanding why loose objects are compressed is that > packfiles were invented much later in the history of git. > > These are both good questions, and it might have made a difference if they > were posed in early April 2005. > > At this point, the plain and clear answer to both of these "Why not" > questions is "because that is the way it is and it is costly to change > them now in thousands of repositories people use every day." > > In other words, it is not interesting anymore to raise these questions > now, especially as a suggestion to change the system, unless they are > accompanied by arguments that convinces everybody that the cost of such a > change outweighs the benefits, and a clear transition plans how to upgrade > everybody's existing repositories without any pain. > Thanks for your explanation, but I doubt if it's too costly to change the format of loose object, after all this doesn't change the format of pack file and affect git-pull/fetch of old git client. I ask the "why not" questions because I doubt if I miss some technical points that the change isn't worth at all in fact. If no severe technical problem will occur, I think it's worth breaking *forward* compatibility for better performance and I'm willing to implement it. Some cons and pros. cons: * old git client can't read loose objects in new format (People degrade git rarely and old git can read pack files generated by new git, so it's not a big problem) pros: * avoid compressing and uncompressing loose objects that are likely frequently used when you are coding/merging * share loose objects among multipe git processes * the new code path is simpler although we will have more code paths for compatibility Best regards, Liu Yubao