Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751192AbVKJSDO (ORCPT ); Thu, 10 Nov 2005 13:03:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751195AbVKJSDO (ORCPT ); Thu, 10 Nov 2005 13:03:14 -0500 Received: from w241.dkm.cz ([62.24.88.241]:12451 "EHLO machine.or.cz") by vger.kernel.org with ESMTP id S1751192AbVKJSDN (ORCPT ); Thu, 10 Nov 2005 13:03:13 -0500 Date: Thu, 10 Nov 2005 19:03:11 +0100 From: Petr Baudis To: Junio C Hamano Cc: "H. Peter Anvin" , git@vger.kernel.org, linux-kernel@vger.kernel.org, barkalow@iabervon.org Subject: Re: [ANNOUNCE] GIT 0.99.9g Message-ID: <20051110180311.GR30496@pasky.or.cz> References: <7vmzkc2a3e.fsf@assigned-by-dhcp.cox.net> <43737EC7.6090109@zytor.com> <7v4q6k1jp0.fsf@assigned-by-dhcp.cox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7v4q6k1jp0.fsf@assigned-by-dhcp.cox.net> X-message-flag: Outlook : A program to spread viri, but it can do mail too. User-Agent: Mutt/1.5.11 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1584 Lines: 36 Dear diary, on Thu, Nov 10, 2005 at 06:44:43PM CET, I got a letter where Junio C Hamano said that... > "H. Peter Anvin" writes: > > > May I *STRONGLY* urge you to name that something different. > > "lost+found" is a name with special properties in Unix; for example, > > many backup solutions will ignore a directory with that name. > > Yeah, the original proposal (in TODO list) explicitly stated why > I chose lost-found instead of lost+found back then, and somebody > on the list (could have been Pasky but I may be mistaken) said > not to worry. It was the Large Angry SCM. I share your concern. > In any case, if we go the route Daniel suggests, we would not be > storing anything on the filesystem ourselves so this would be a > non-issue. I like Daniel's route as well, for the separate command. But it would be nice to also have a way to tell git-fsck-cache to save the lost+found refs as it goes, much like the filesystem fsck. So if it reports some unreachable refs, you will not need to tell it to do the same job _another_ time to find out the refs and pass them to gitk. Then again, if we do this, the utility of a separate command will be questionable. -- 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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/