From: Jeff King <peff@peff.net>
To: Michael Witten <mfwitten@gmail.com>
Cc: Peter Kleiweg <pkleiweg@xs4all.nl>, git@vger.kernel.org
Subject: Re: file mode
Date: Mon, 13 Jun 2011 01:38:14 -0400 [thread overview]
Message-ID: <20110613053814.GA2680@sigill.intra.peff.net> (raw)
In-Reply-To: <BANLkTimh=-caLH5dVaUeXXmcF21+=-o0tw@mail.gmail.com>
On Sun, Jun 12, 2011 at 07:12:42PM +0000, Michael Witten wrote:
> On Sun, Jun 12, 2011 at 18:57, Peter Kleiweg <pkleiweg@xs4all.nl> wrote:
> > I added a file that has file mode 600. When I do a check-out,
> > the file comes with mode 644. Is this supposed to happen? Then
> > how do I control what permissions files have?
>
> Do some googling.
I really don't see the point of a response like this. It is one thing to
rudely point somebody to lmgtfy or an FAQ link. Then you're still being
rude, but at least you are pointing them in the right direction. But
this seems simply to make the list a less pleasant place _and_ to be
totally useless to the original poster. If you didn't want to give the
answer, wouldn't it have been better not to respond at all?
Peter:
This is by design. While the git data structure can technically store
unix mode bits in its trees, it was found early on in git's history that
respecting anything beyond a simple executable bit ended up being more
cumbersome for git's normal use cases (i.e., people storing code or
other shared files in a repository).
We could add in a config option to respect file modes, but it has
generally been seen as not worthwhile. It solves only a part of the
general metadata problem, as it omits owner and group names or ids, as
well as extended metadata like ACLs.
If modes are important to you, the suggested fixes are one of:
1. Use a tool like "metastore" that can be called from git hooks, and
will save and restore file permissions in a file that is tracked in
the repository. Do note that when using such a tool there is a race
condition in protecting files (i.e., git will create your file as
644, and then metastore will correct it to 600; in the meantime,
somebody could read your file).
2. Depending on exactly what you're storing, it may make sense to keep
your repository in another directory, protected by permissions, and
then use a separate tool to deploy your files from the repository
to their ultimate location (e.g., a Makefile or other install
tool).
-Peff
PS I actually _did_ try googling for this, and didn't come up with an
answer that was as complete or clear (to me, anyway) as what I wrote
above.
next prev parent reply other threads:[~2011-06-13 5:38 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-12 18:57 file mode Peter Kleiweg
2011-06-12 19:12 ` Michael Witten
2011-06-13 5:38 ` Jeff King [this message]
2011-06-13 13:52 ` Dirk Süsserott
2011-06-13 13:58 ` Michael Witten
2011-06-13 13:58 ` Michael Witten
2011-06-13 21:18 ` Ævar Arnfjörð Bjarmason
2011-06-14 5:51 ` Michael Witten
2011-06-13 14:25 ` Peter Kleiweg
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=20110613053814.GA2680@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=mfwitten@gmail.com \
--cc=pkleiweg@xs4all.nl \
/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;
as well as URLs for NNTP newsgroup(s).