From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: jidanni@jidanni.org, git@vger.kernel.org
Subject: Re: why not preserve file permissions?
Date: Fri, 5 Dec 2008 20:29:14 -0500 [thread overview]
Message-ID: <20081206012913.GA2910@coredump.intra.peff.net> (raw)
In-Reply-To: <7vljuuxn66.fsf@gitster.siamese.dyndns.org>
On Fri, Dec 05, 2008 at 02:38:41PM -0800, Junio C Hamano wrote:
> Actually in a very early days, git used to record the full (mode & 0777)
> for blobs.
>
> Once people started using git, everybody realized that it had a very
> unpleasant side effect that the resulting tree depended on user's umasks,
Note, of course that "everybody" in your sentence is "everybody who was
using git as a source control mechanism." I think as git has grown,
people have wanted to use it to version other things, such as dot files
in their home directory or the contents of /etc, two situations where
file metadata might be of as much interest as the file content.
And I don't see a real problem in a config switch or two to handle a
vastly different workflow like that, if it can be done with minimal
intrusion. For example, now we throw away most of the mode bits; it
would probably only be a few lines of code difference to keep those mode
bits, people who turned on that config option would presumably know what
they are doing, and performance for the usual workflow would be
unaffected.
_But_ I think people who ask for just permission bits aren't really
thinking things through. Those bits are only one part of the metadata.
There's file owner and group. There are timestamps. There are
non-regular files with their own associated metadata (like major/minor
device numbers). There are extended attributes, which covers things like
ACLs (and I don't even know if there's a standard representation that
can cover the ACLs for all platforms we support).
And those things _aren't_ as easy as flipping a config switch. They mean
changes to the fundamental data structures of git, and all of the pain
that entails: a lot of code, interoperability annoyances, and probably
performance impacts for unrelated workflows.
So I am sympathetic to somebody who, after thinking it through, has a
use case that just requires tracking permissions bits and wants a config
option for git to do that. But the commonly given examples seem much
better served by a _full_ metadata solution that lives on top of git,
like metastore. I haven't seen a compelling argument for just handling
permission bits.
-Peff
next prev parent reply other threads:[~2008-12-06 1:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-05 20:08 why not preserve file permissions? jidanni
2008-12-05 22:23 ` Jakub Narebski
2008-12-05 22:38 ` Junio C Hamano
2008-12-06 1:29 ` Jeff King [this message]
2008-12-06 0:05 ` Daniel Barkalow
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=20081206012913.GA2910@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jidanni@jidanni.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox