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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jul 22, 2007, 21:52 UTC
Message-ID: <Pine.LNX.4.64.0707222246220.14781@racer.site>
In-Reply-To: <7vodi4qfnx.fsf@assigned-by-dhcp.cox.net>

Hi,

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

Show 10 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > 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".

Show 8 quoted lines

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