Re: [ANNOUNCE] GIT 0.99.9g

"H. Peter Anvin" [off-list ref] 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.  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.

Dear diary, on Thu, Nov 10, 2005 at 06:44:43PM CET, I got a letter
where Junio C Hamano [off-list ref] said that...

"H. Peter Anvin" [off-list ref] writes:

quoted

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.

On Thu, 10 Nov 2005, Petr Baudis wrote:

Dear diary, on Thu, Nov 10, 2005 at 06:44:43PM CET, I got a letter
where Junio C Hamano [off-list ref] said that...

quoted

"H. Peter Anvin" [off-list ref] writes:

quoted

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.

quoted

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.

Maybe git-fsck-objects should have an option to make it note dangling 
objects of certain types, and then count these as reachable? (That is, you 
want the head of an unreachable chain listed for recovery, but not other 
things reachable from it; you also may want the list of blobs and trees 
not reachable either from a ref or from something listed for recovery, but 
not omitting a blob reachable only from an unreachable tree)

	-Daniel
*This .sig left intentionally blank*

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

On Thu, 10 Nov 2005, Linus Torvalds wrote:

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. 

                 ^^^^^^^

That should be "dangling", of course. 

		Linus

Junio C Hamano wrote:

"H. Peter Anvin" [off-list ref] writes:

quoted

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.  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.

Just realized one more issue with this... a lot of non-Unix filesystems 
can't deal with files with a + sign.

	-hpa