All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: martin f krafft <madduck@madduck.net>
Cc: git discussion list <git@vger.kernel.org>,
	Benoit SIGOURE <tsuna@lrde.epita.fr>
Subject: Re: confused about preserved permissions
Date: Thu, 23 Aug 2007 00:03:18 -0700	[thread overview]
Message-ID: <7vodgyvikp.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20070823060052.GA25153@piper.oerlikon.madduck.net> (martin f. krafft's message of "Thu, 23 Aug 2007 08:00:52 +0200")

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

> 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.

      parent reply	other threads:[~2007-08-23  7:03 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-20 16:44 confused about preserved permissions martin f krafft
2007-08-20 16:54 ` Pierre Habouzit
2007-08-20 17:38   ` martin f krafft
2007-08-20 17:41 ` Mike Hommey
2007-08-20 17:58   ` David Kastrup
2007-08-20 18:13     ` Mike Hommey
2007-08-20 18:44       ` David Kastrup
     [not found]       ` <86zm0mgicy.fsf@lola.quinscape.zz>
2007-08-20 18:48         ` Mike Hommey
2007-08-20 19:43           ` Jan Hudec
2007-08-20 19:50             ` Mike Hommey
2007-08-20 20:07               ` Alex Riesen
2007-08-20 20:10                 ` Mike Hommey
2007-08-20 20:27                   ` Jan Hudec
2007-08-20 20:42                   ` David Kastrup
2007-08-20 20:44                     ` Mike Hommey
2007-08-20 20:08               ` Jan Hudec
2007-08-20 20:39           ` David Kastrup
2007-08-20 20:50             ` Mike Hommey
2007-08-20 21:03               ` David Kastrup
2007-08-21  1:35               ` Shawn O. Pearce
2007-08-21  2:06                 ` Junio C Hamano
2007-08-21  5:34                   ` Mike Hommey
2007-08-21  6:04                     ` David Kastrup
2007-08-21 18:01   ` René Scharfe
2007-08-21 18:01   ` [PATCH] Documentation: update tar.umask default René Scharfe
2007-08-21 21:15     ` Mike Hommey
2007-08-22 21:03       ` René Scharfe
2007-08-20 18:35 ` confused about preserved permissions Alex Riesen
2007-08-22 12:18 ` Benoit SIGOURE
2007-08-22 12:52   ` Johannes Sixt
2007-08-22 22:09   ` Junio C Hamano
2007-08-23  6:00     ` martin f krafft
2007-08-23  6:12       ` David Kastrup
2007-08-23  6:23         ` martin f krafft
2007-08-23  7:48         ` Benoit SIGOURE
2007-08-23  7:57           ` Junio C Hamano
2007-08-23  8:08             ` David Kastrup
2007-09-03 18:59           ` Jan Hudec
2007-08-23  7:03       ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vodgyvikp.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=madduck@madduck.net \
    --cc=tsuna@lrde.epita.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.