On Thu, 10 Nov 2005, Junio C Hamano wrote:
>
> 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 linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
