Edward Thomson <ethomson@xxxxxxxxxxxxxxxxx> writes: > In any case, it sounds like you're not particularly interested in > this, although I certainly appreciate you taking the time to suggest > improvements despite that. There's some good feedback there. Not in its current shape. But do not take this in a wrong way. It may be useful in a third-party script collection in its current shape already. More importantly, I am not opposed to have a "resurrect" utility in the core distribution. It just has to be a lot better than what "grep -e 'I think I wrote this string' .git/lost-found/other/*" gives us. Filename discovery (perhaps from lost trees, which was the idea I wrote in the message I am responding to, but others may come up with better alternatibve approaches) is a must, but not primarily because such a grep won't find the path to which the contents should go. When a user says "I think I wrote this string in the file I am looking for", s/he already knows what s/he wants to recover (i.e. it was a README file at the top-level). Filename discovery is a must because grepping in the raw blob contents without smudge filter chain applied may not find what we want in the first place, and for that to happen, we need to have a filename. Side note. That may mean that even working in the do-recover mode, the script may want to take a filename, letting the user to say "pretend all lost blobs are of this type, as that is the type of the blob I just lost and am interested in, and a filename will help you find an appropriate smudge and/or textconv filter to help me" That makes me realize that I did not mention one more thing, other than the "interactibve loop", I did like in the script over what lost-found gives us: smudge filter support. I do not very often work with contents that needs clean/smudge other than in one project (obviously not "git.git"), and I can see how it is essential in helping the user to find the contents the user is looking for. Thanks.
