OK, here it is with tests and a commit message. I dug around to make sure there were no cases where the unusual mode would cause other behavior changes, but there aren't any. We are careful to use the canonical mode whenever we create a file.
So the tests here may be overkill (since except for the warning message, they'd pass already), but I thought it worth demonstrating the complete set of expected behavior. Likewise the commit message is long because I laid out all of the things I poked at.
I didn't add tests confirming that we complain when the executable bit is not as expected. Earlier tests in t4129 already cover that.
-- >8 --
Subject: apply: canonicalize modes read from patches
Git stores only canonical modes for blobs. So for a regular file, we care about only "100644" or "100755" (depending only on the executable bit), but never modes where the group or other permissions are more exotic. So never "100664", "100700", etc. When a file in the working tree has such a mode, we quietly turn it into one of the two canonical modes, and that's what is stored both in the index and in tree objects.
However, we don't canonicalize modes we read from incoming patches in git-apply. These may appear in a few lines:
- "old mode" / "new mode" lines for mode changes
- "new file mode" lines for newly created files
- "deleted file mode" for removing files
For "new mode" and for "new file mode", this is harmless. The patch is asking the result to have a certain mode, but:
- when we add an index entry (for --index or --cached), it is
canonicalized as we create the entry, via create_ce_mode(). - for a working tree file, try_create_file() passes either 0777 or
0666 to open(), so what you get depends only on your umask, not any
other bits (aside from the executable bit) in the original mode.However, for "old mode" and "deleted file mode", there is a minor annoyance. We compare the patch's expected preimage mode with the current state. But that current state is always going to be a canonical mode itself:
- updating an index entry via --cached will have the canonical mode in
the index - for updating a working tree file, check_preimage() runs the mode
through ce_mode_from_stat(), which does the usual canonicalizationSo if the patch feeds a non-canonical mode, it's impossible for it to match, and we will always complain with something like:
file has type 100644, expected 100664
Since this is just a warning, the operation proceeds, but it's confusing and annoying.
These cases should be pretty rare in practice. Git would never produce a patch with non-canonical modes itself (since it doesn't store them). And while we do accept patches from other programs, all of those lines were invented by Git. So you'd need a program trying to be Git compatible, but not handling canonicalization the same way. Reportedly "quilt" is such a program.
We should canonicalize the modes as we read them so that the user never sees the useless warning.
A few notes on the tests:
- I've covered instances of all lines for completeness, even though
the "new mode" / "new file mode" ones behave OK currently. - the tests apply patches to both the index and working tree, and
check the result of both. Again, we know that all of these paths
canonicalize anyway, but it's giving us extra coverage (although we
are even less likely to have such a bug now since we canonicalize up
front). - the test patches are missing "index" lines, which is also something
Git would never produce. But they don't matter for the test, they do
match the case from quilt we saw in the wild, and they avoid some
sha1/sha256 complexity.Reported-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Jeff King <peff@peff.net>
---
apply.c | 1 +
t/t4129-apply-samemode.sh | 62 +++++++++++++++++++++++++++++++++++++++
2 files changed, 63 insertions(+)
