Jeff King <peff@xxxxxxxx> writes:
> Given that, I think it is reasonable for git to also normalize the mode
> of the patches it reads, so that we are consistently working in the
> world of simplified modes. I.e., this:
>
> diff --git a/apply.c b/apply.c
> index 142e3d913c..3d50fade78 100644
> --- a/apply.c
> +++ b/apply.c
> @@ -995,6 +995,7 @@ static int parse_mode_line(const char *line, int linenr, unsigned int *mode)
> *mode = strtoul(line, &end, 8);
> if (end == line || !isspace(*end))
> return error(_("invalid mode on line %d: %s"), linenr, line);
> + *mode = canon_mode(*mode);
> return 0;
> }
>
>
> which makes the warning go away in the example above. But I'm not sure
> if there could be other fallout. E.g., is there a mode for git-apply to
> just touch the working tree and not the index, where we'd perhaps want
> to retain the original to compare against the filesystem mode? I don't
> think so.
Makes sense.
The above is consistent with what we do for the permission bits;
only the execute bit matters, and the patch recording 100664 should
mean the same thing to us as permission bits 100644---we should warn
if the on-disk file is executable while applying such a patch, and
we should not warn otherwise.
> Alternatively (or maybe in addition), I wonder if quilt should similarly
> canonicalize the mode. git-apply is certainly meant to work with patches
> generated elsewhere, but normal patches don't have modes in them at all.
> The "deleted file mode" line is git-ism, so here we have something which
> is implementing the git line in a (slightly) incompatible way.
It's an orthogonal fix and probably worth doing.
If a third-party tool adds git-ism mode lines, we should be lenient
when we see a wrong mode, as long as the leniency does not affect
our normal mode of operation negatively. It is OK if they record a
non-executable regular file with 100666. Using 664 (no type bits)
or 100755, however, crosses the line and they must stop producing
such a bogus mode line, if they do not want to see a warning.
