On Sun, Jun 12, 2011 at 07:12:42PM +0000, Michael Witten wrote:
> On Sun, Jun 12, 2011 at 18:57, Peter Kleiweg <pkleiweg@xxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html