git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
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.

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