On Thu, 10 Nov 2005, Junio C Hamano wrote:
quoted text
> 
> 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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html