On Thu, Dec 20, 2018 at 6:32 PM Jeff King <peff@xxxxxxxx> 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@xxxxxxxx> 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
