From: Jeff King <peff@peff.net>
To: Duy Nguyen <pclouds@gmail.com>
Cc: "brian m. carlson" <sandals@crustytoothpaste.net>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH] diff: add support for reading files literally with --no-index
Date: Thu, 20 Dec 2018 12:32:05 -0500 [thread overview]
Message-ID: <20181220173204.GC6684@sigill.intra.peff.net> (raw)
In-Reply-To: <CACsJy8AFwSgL-YAc2YU2XfqKFkXf-W+2V7tMy3ZOYvm_zhv5Bg@mail.gmail.com>
On Thu, Dec 20, 2018 at 06:23:42PM +0100, Duy Nguyen wrote:
> On Thu, Dec 20, 2018 at 6:18 PM Jeff King <peff@peff.net> wrote:
> > > I wonder if --follow-symlinks would be a good alternative for this
> > > (then if the final destination is unmmapable then we just read the
> > > file whole in memory without the user asking, so it will work with
> > > pipes). --follow-symlinks then could be made work with non-"no-index"
> > > case too. But --literally is also ok.
> >
> > It's more than symlinks, though. Reading from a named pipe, we'd want to
> > see the actual contents with --literally (and not "oops, I don't know
> > how to represent a named pipe").
>
> Yes, but I think at least --no-index it makes sense to just fall back
> to read() if we can't mmap(). mmap is more of an optimization than a
> requirement. There's no loss going from "oops I don't know how to
> represent it" to "here's the content from whatever what that device
> is". Symlinks are different because we have two possible
> representations and the user should choose.
Oh, I see. I misread your paragraph. Yeah, I think that is the behavior
I would want by default, too, though the previous thread makes me thing
some people would literally rather have the "I can't represent this"
behavior (because they really do want a diff that can reconstruct the
filesystem state, and an error if not).
-Peff
next prev parent reply other threads:[~2018-12-20 17:32 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-20 0:26 [PATCH] diff: add support for reading files literally with --no-index brian m. carlson
2018-12-20 15:48 ` Jeff King
2018-12-21 0:25 ` brian m. carlson
2018-12-20 17:06 ` Duy Nguyen
2018-12-20 17:17 ` Jeff King
2018-12-20 17:23 ` Duy Nguyen
2018-12-20 17:32 ` Jeff King [this message]
2018-12-20 17:37 ` Duy Nguyen
2018-12-20 21:43 ` Ævar Arnfjörð Bjarmason
2018-12-20 23:54 ` brian m. carlson
2018-12-21 11:52 ` Johannes Schindelin
2018-12-21 23:20 ` brian m. carlson
2019-01-02 18:56 ` Junio C Hamano
2019-01-04 2:08 ` brian m. carlson
2019-01-04 2:18 ` Jonathan Nieder
2019-01-04 2:57 ` brian m. carlson
2019-01-04 19:26 ` Junio C Hamano
2019-01-05 17:39 ` brian m. carlson
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181220173204.GC6684@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=pclouds@gmail.com \
--cc=sandals@crustytoothpaste.net \
/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.
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 NNTP newsgroup(s).