Re: Honor extractor's umask in git-tar-tree.

Junio C Hamano wrote:

"H. Peter Anvin" [off-list ref] writes:

quoted

My point is that I believe it should.  It has the bitfield for it, it 
just doesn't use it at the moment.

It is a bit more complicated than that.

Long time ago, we used to store the full permission bits and
ended up storing files in 0644 and 0664 modes, depending on who
is writing the tree object.  People with umask 022 checked out
from a tree that recorded blobs with 0664 bits and ended up
getting "mode changed" diff all the time, which was unacceptable
from the SCM point of view.  We _could_ have really changed the
mode bits representation in the tree objects back then to have
type + executable bit, but to preserve backward compatibility,
we chose to keep the bitfield layout and changed the code to
treat 1006xx and 1007yy in older trees to be equivalent to
100644 and 100755.  These days, for newly written tree objects,
above xx and yy 6-bit fields are "Must Be 4" and "Must Be 5"
fields, respectively, not bitfields to store arbitrary group and
other permission information.  git-fsck-objects even complains
about them.

So in that sense, it does _not_ have the bitfield for it, and
obviously we cannot use what we do not have.

Welcome to the wonderful world of evolving file formats.

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.

In the case of git, there isn't just the requirement to maintain old 
formats indefinitely (due to the cryptographic chain), but also that new 
objects that are compatible with old format should be written in the old 
format to maintain the aliasing properties.  These are obstacles that 
are perfectly possible to overcome, although it takes a bit of legwork.

If the old-format (with random write bits) is out of circulation -- 
which I can't tell for sure they it is, but Linus' kernel tree doesn't 
seem to have any of these objects -- then the answer is very simple: 
redefine this field _a posteori_ to be the mode ^ 022 (or perhaps more 
sanely,
mode ^ (mode & 0200 ? 022 : 0)).  Compatibility and contents is fully 
preserved.  No problem.

If there are still old-format trees in circulation and compatibility 
with these very old trees need to be maintained, then it's a bit more 
complicated, but literally just a bit.  This data is already stored in 
text form in the object store, so there aren't any funnies with 
expanding it.  For example, encode a leading + on the octal value if 
this is a value with "I really mean it" permissions (and *only* those 
values.)  This is even readable by older versions of git, since they 
will just blindly ignore the + sign.

	-hpa