Hi, On Sun, 22 Jul 2007, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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". > 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
