From: Duy Nguyen <pclouds@gmail.com>
To: Jeff King <peff@peff.net>
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 18:37:07 +0100 [thread overview]
Message-ID: <CACsJy8C6JZR=6bh0M2=9P_LD42tW1qz78+xL3aqTw5A0fJCrqg@mail.gmail.com> (raw)
In-Reply-To: <20181220173204.GC6684@sigill.intra.peff.net>
On Thu, Dec 20, 2018 at 6:32 PM Jeff King <peff@peff.net> wrote:
>
> 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).
I can't see a good use case for that. But yeah it would not harm to be
a bit more conservative, then make --literally default later and leave
--no-literally as an escape hatch.
--
Duy
next prev parent reply other threads:[~2018-12-20 17:37 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
2018-12-20 17:37 ` Duy Nguyen [this message]
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
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='CACsJy8C6JZR=6bh0M2=9P_LD42tW1qz78+xL3aqTw5A0fJCrqg@mail.gmail.com' \
--to=pclouds@gmail.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--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.
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).