From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Shawn O. Pearce" Subject: Re: two questions about the format of loose object Date: Mon, 1 Dec 2008 07:21:48 -0800 Message-ID: <20081201152148.GG23984@spearce.org> References: <493399B7.5000505@gmail.com> <7voczws3np.fsf@gitster.siamese.dyndns.org> <4933AE55.2090007@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Junio C Hamano , git list To: Liu Yubao X-From: git-owner@vger.kernel.org Mon Dec 01 16:23:11 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 1L7Ac7-0008TC-A4 for gcvg-git-2@gmane.org; Mon, 01 Dec 2008 16:23:07 +0100 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751337AbYLAPVu (ORCPT ); Mon, 1 Dec 2008 10:21:50 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751334AbYLAPVu (ORCPT ); Mon, 1 Dec 2008 10:21:50 -0500 Received: from george.spearce.org ([209.20.77.23]:52303 "EHLO george.spearce.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751252AbYLAPVt (ORCPT ); Mon, 1 Dec 2008 10:21:49 -0500 Received: by george.spearce.org (Postfix, from userid 1001) id 9FD7A38200; Mon, 1 Dec 2008 15:21:48 +0000 (UTC) Content-Disposition: inline In-Reply-To: <4933AE55.2090007@gmail.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Liu Yubao wrote: > 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. It is too costly; Jakub pointed out the dumb protocol clients would have issues with the new format. Anyone copying a repository between machines using scp or a USB memory stick may also run into a problem. Etc. > 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) That's a pretty big con. We can also add slower performance on NFS, as has been reported already by others. > pros: > > * avoid compressing and uncompressing loose objects that are likely > frequently used when you are coding/merging True, loose objects are among the more frequently accessed items. > * share loose objects among multipe git processes Probably not a huge issue. How many concurrent git processes are you running on the same object store at once? During development? Its probably not more than 1. So sharing the objects doesn't make a very compelling argument. > * the new code path is simpler although we will have more code paths for > compatibility The new code path is more complex, because although one branch is very simple (mmap and use) the other code paths have to stay for backwards compatibility. Every time you add a branch point the code gets more complex. It works well enough now, and is at least one branch point simpler than what you are proposing. So I'm not really interested in seeing the change made. -- Shawn.