From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Pitre Subject: Re: Distribution of longest common hash prefixes Date: Tue, 03 Apr 2007 16:39:02 -0400 (EDT) Message-ID: References: <20070402145857.GA13293@bohr.gbar.dtu.dk> <86bqi6kae7.fsf@blue.stonehenge.com> <86y7laitlz.fsf@blue.stonehenge.com> <86r6r2isva.fsf@blue.stonehenge.com> <867istcrhr.fsf@blue.stonehenge.com> <20070403172123.GD27706@spearce.org> <7vhcrxz5a8.fsf@assigned-by-dhcp.cox.net> <7vhcrxw6h5.fsf@assigned-by-dhcp.cox.net> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Content-Transfer-Encoding: 7BIT Cc: Linus Torvalds , "Shawn O. Pearce" , "Randal L. Schwartz" , James Cloos , git@vger.kernel.org, Peter Eriksen To: Junio C Hamano X-From: git-owner@vger.kernel.org Tue Apr 03 22:39:35 2007 Return-path: Envelope-to: gcvg-git@gmane.org Received: from vger.kernel.org ([209.132.176.167]) by lo.gmane.org with esmtp (Exim 4.50) id 1HYpmv-0005Oy-M4 for gcvg-git@gmane.org; Tue, 03 Apr 2007 22:39:34 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1945925AbXDCUjG (ORCPT ); Tue, 3 Apr 2007 16:39:06 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1945933AbXDCUjG (ORCPT ); Tue, 3 Apr 2007 16:39:06 -0400 Received: from relais.videotron.ca ([24.201.245.36]:25441 "EHLO relais.videotron.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1945925AbXDCUjE (ORCPT ); Tue, 3 Apr 2007 16:39:04 -0400 Received: from xanadu.home ([74.56.106.175]) by VL-MO-MR002.ip.videotron.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0JFX00H94W12Z460@VL-MO-MR002.ip.videotron.ca> for git@vger.kernel.org; Tue, 03 Apr 2007 16:39:02 -0400 (EDT) In-reply-to: <7vhcrxw6h5.fsf@assigned-by-dhcp.cox.net> X-X-Sender: nico@xanadu.home Sender: git-owner@vger.kernel.org Precedence: bulk X-Mailing-List: git@vger.kernel.org Archived-At: On Tue, 3 Apr 2007, Junio C Hamano wrote: > I stated it wrongly. What I was getting at was that we might > want to consider an abbreviation that matches only a single > commit unambiguous even when there are ambiguous objects of > other kinds. Maybe. But by the time your object hash distribution starts showing ambiguous objects with a given abbreviated name between a commit and a non commit, I'll bet you'll start to see ambiguities between commits soon enough as well. > Not that I consider it a pressing issue, though. Indeed. And even then it is not something really hard to implement either. Nicolas