Re: [PATCH] diff: add support for reading files literally with --no-index

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Dec 21, 2018, 00:25 UTC
Message-ID: <20181221002527.GF35965@genre.crustytoothpaste.net>
In-Reply-To: <20181220154841.GE27361@sigill.intra.peff.net>

On Thu, Dec 20, 2018 at 10:48:41AM -0500, Jeff King wrote:

> The distinction is a bit subtle, but I think treating only the actual
> top-level arguments as symlinks would solve your problem, but still
> allow a more detailed diff for the recursive cases.

Yeah, I think that would be better. I'll add a test.

> Looks like spaces for indent, whereas the context uses tabs.

Will fix.

Show 9 quoted lines

> I think "literal" is a good way to describe this concept. If we do grow
> a config option to make this the default, then countermanding it would
> be "--no-literally", which parses a bit funny as English.
> 
> If you agree with my "only the top-level" line of reasoning above, maybe
> "--literal-arguments" and "--no-literal-arguments" might make sense.
> 
> We could also in theory offer several levels: no literals, top-level
> literals, everything literal, at which point it becomes a tri-state.

Yeah, this is what the POSIX symlink options (-H, -L, -P) do. I originally came up with "--dereference" as the name, but I decided to change it, because it doesn't affect just symlinks. I think --literal-arguments is better.

Theoretically, we could adopt the POSIX options for symlink/pipe handling if we want to in the future, but I think that's a decision we should make later.

Show 13 quoted lines

> > diff --git a/diff.c b/diff.c
> > index dc9965e836..740d0087b9 100644
> > --- a/diff.c
> > +++ b/diff.c
> > @@ -4282,18 +4282,18 @@ static void run_diff_cmd(const char *pgm,
> >  		fprintf(o->file, "* Unmerged path %s\n", name);
> >  }
> >  
> > -static void diff_fill_oid_info(struct diff_filespec *one, struct index_state *istate)
> > +static void diff_fill_oid_info(struct diff_filespec *one, struct diff_options *o)
> 
> It might be worth breaking these "pass the options around" hunks into a
> separate preparatory patch.

I can do that.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204