Edward Thomson <ethom...@edwardthomson.com> 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.
