Re: [PATCH] fsck --lost-found: write blob's contents, not their SHA-1

Hi,

On Sun, 22 Jul 2007, Junio C Hamano wrote:

Johannes Schindelin [off-list ref] writes:

quoted

When looking for a lost blob, it is much nicer to be able to grep
through .git/lost-found/other/* than to write an inefficient loop
over the file names.  So write the contents of the dangling blobs,
not their object names.

I think this is an idea to solve a good problem, but if we go
this route, the need for us to worry about expiring lost-found
entries would become more urgent, I suspect.

Why?  AFAICT lost+found/ has to be cleaned by people.  So if you look for 
something, you say "git fsck --lost-found", and once you found it, it's 
time for "rm -rf .git/lost-found".

And when you think about expiring lost-found entries, another
possible solution emerges.  If we teach git-prune to remove the
corresponding entry from lost-found/other when it removes a
loose blob from the object store, then we can easily and safely
do this instead:

	$ cat .git/lost-found/other/* |
	  xargs -r git grep 'the word to look for'

Well, it is not only for grepping.  In my case, I could get away by this:

$ ls -lrt $(grep -l filter_subdir .git/lost-found/other/* |
	sed "s/^.*other\/\(..\)/.git\/objects\/\1\//") 

IOW I found the loose dangling objects which matched a keyword, and sorted 
them by time.

In other cases, though, I wanted to see the size.

But what the whole thing boils down to: After finding dangling objects, 
you are much more likely using git tools on non-blobs than on blobs, and 
vice versa.

Ciao,
Dscho

P.S.: I fully forgot to mention that happily, I did "git add -u" sometime 
before "git reset --hard", otherwise I would have been lost.