Re: [ANNOUNCE] GIT 0.99.9g

From: Linus Torvalds <torvalds@osdl.org>
Date: Nov 10, 2005, 19:32 UTC
Message-ID: <Pine.LNX.4.64.0511101128510.4627@g5.osdl.org>
In-Reply-To: <7v4q6k1jp0.fsf@assigned-by-dhcp.cox.net>

On Thu, 10 Nov 2005, Junio C Hamano wrote:

Show 7 quoted lines

> 
> 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.  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 don't know how many people do this, but with the current kernel sources, "git-fsck-cache --full" takes about a minute on a reasonable fast machine with everything in cache (ie no real disk activity to speak of)

I personally think that's fine, since I repack my trees every once in a while, and almost never run a "--full" check, I only do incrementals (which are basically free). And I suspect that I run fsck a lot more than anybody else does.

But the point is, that if you actually run fsck every time you want to visualize your pending commits, you're going to feel the pain.

I think having some kind of lost+found so that you don't have to re-run fsck just because you decided to look at them some other way (use "git log" instead of "gitk" or whatever) makes a lot of sense. But yes, it shouldn't really be called "lost+found" due to some rather serious confusion that can cause.

		Linus