From: Junio C Hamano <gitster@pobox.com>
To: Edward Thomson <ethomson@edwardthomson.com>
Cc: git@vger.kernel.org
Subject: Re: [RFC PATCH 1/1] recover: restoration of deleted worktree files
Date: Sat, 04 Aug 2018 09:48:18 -0700 [thread overview]
Message-ID: <xmqqh8kat6wd.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20180804161956.GA6@1032a7a09014> (Edward Thomson's message of "Sat, 4 Aug 2018 16:19:56 +0000")
Edward Thomson <ethomson@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.
next prev parent reply other threads:[~2018-08-04 16:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-04 14:22 [RFC PATCH 0/1] Introduce git-recover Edward Thomson
2018-08-04 14:24 ` [RFC PATCH 1/1] recover: restoration of deleted worktree files Edward Thomson
2018-08-04 15:54 ` Junio C Hamano
2018-08-04 16:17 ` Robert P. J. Day
2018-08-04 17:33 ` Todd Zullinger
2018-08-04 16:19 ` Edward Thomson
2018-08-04 16:48 ` Junio C Hamano [this message]
2018-08-05 1:34 ` [RFC PATCH 0/1] Introduce git-recover Jonathan Nieder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqh8kat6wd.fsf@gitster-ct.c.googlers.com \
--to=gitster@pobox.com \
--cc=ethomson@edwardthomson.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).