Re: confused about preserved permissions

martin f krafft [off-list ref] writes:

also sprach Junio C Hamano [off-list ref] [2007.08.23.0009 +0200]:

quoted

We deliberately chose not to use that space, and this default is
very unlikely to change.

The downsides included change in SHA hash on mode change, as far as
I can remember. Anything else?

More serious practical problem was that sane developers tend to
have either 022 or 002 umask.  You may check out my project
(whose regular files are either 0664 or 0775, according to my
umask settings), but the checkout honors your umask and you
would get 0644 or 0755 on your copies, and you would check in
with differemtn modes.  The merge I would do later with you
would get needless conflicts on modes.

What makes the mode conflict "needless" is that we are primarily
talking about source code control, by the way.  It is very
reasonable if you want to retarget git, probably borrowing most
of its infrastructure, to build a backup system to keep track of
files in /etc hierarchy.  It would be crucial for _your_ system
to keep track of owner/group and mode bits.  If the modes or
ownership conflict during a merge, that is _not_ needless
conflict at all --- the user needs to decide if /etc/shadow
should or should not be world readable, and send a nasty message
to whoever asked you to pull such a change to make the file
world readable after you detect such a mistake while you are
merging.  It becomes essential to your "backup" system.

But in the context of git project, and source code management,
which is its primary application, it is not worth to keep track
of such mode differences that come from umask differences of
contributors.  You could add such a full-mode-bits and ownership
support to git, but that would stay secondary at best.  It is
entirely possible that the code to support such an extension
would be too intrusive to clutter git codebase, at which point
the "backup" application may have to become a fork of git, not
part of it.