Re: Honor extractor's umask in git-tar-tree.
From: Junio C Hamano <hidden>
Date: 2016-06-15 22:42:07
"H. Peter Anvin" [off-list ref] writes:
As you stated above, we currently use this field in a very inefficient manner, because of old mistakes. There are several ways to recover from here, some of which are more complex than others.
Solution for in-tree permission mode bits you outlined looked
fine (I'll have to re-read the part about "mode xor (mode &
022)..." part later, though).
For in-cache permission mode bits, we would probably need
something like this:
* git-update-index will pick up the filesystem bits with the
current semantics (i.e. look only at (mode & 0100) and
force 0644 or 0755) by default; --full-perm-bits option
would bypass this bits munging.
Once a file is added with --full-perm-bits, it might be
nice if index file remembers to pick up the full bits next
time git-update-index is run on the path. This could be
achieved by saying that anything stored in the cache with
non 100644, 100755 nor 120000 bits are such paths without
having to change the index file format.
* there are bunch of codes that assume 0644 and 0755 are the
norm but also know that there are ancient trees that have
0664 and 0775 and try to treat them equivalently. They need
to be selectively neutered; this applies to in-tree
permission bits as well.
git-read-tree will read permission mode bits from tree
object as-is. I.e. you will get 0644 and 0755 in cache from
the existing tree objects. When you check things out with
002 umask, you will get 0664 and 0775 on the filesystem. We
do not want to consider this "mode changed by the user".
git-update-index --refresh code should not be mode neutered
to prevent this. The same thing goes for diff. These
currently canonicalize mode bits by looking at (mode &
0100), but should be changed to do so only when index has
already the canonical mode bits, or something like that.
* git-write-tree and git-fsck-objects probably has code to
reject and correct abnormal mode bits. They need to be
neutered.