Re: confused about preserved permissions

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 23, 2007, 07:03 UTC
Message-ID: <7vodgyvikp.fsf@gitster.siamese.dyndns.org>
In-Reply-To: <20070823060052.GA25153@piper.oerlikon.madduck.net>

martin f krafft <madduck@madduck.net> writes:

Show 6 quoted lines

> also sprach Junio C Hamano <gitster@pobox.com> [2007.08.23.0009 +0200]:
>> 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.