On Tue, 9 Dec 2014 10:32:28 -0800 (PST)
leam hall <leamh...@gmail.com> wrote:

> Is there a HOWTO or tutorial for how to control owner, group, and 
> permissions on files as they get checked in? The ideal is that the
> owner and group change to "X" and "Y" and the permissions are set to
> 770. I'd like to figure out how to do and test that.

No way.  Git does not track permissions beyoud the executable bit; and
it also handles symlinks and submodules using the "file mode" field in
the trees it stores.  Owner user and group are not tracked at all.

The rationale for this is quite simple: all this stuff has no sense
outside of a particular developer's computer, and, Git is not a
deployment tool.

So what you can do about this.

1) Stop using Git for deployment and use a real deployment solution.

2) Maintain a script along with your code which is respolsible for
   traversing the checkout it's pointed at and setting correct ownership
   and permission bits.  Run it as a part of deployment sequence.

3) Devise a way to store metainformation on the ownership/permissions
   in Git itself along with the commits, at deployment site have a tool
   which is taught to extract this information and apply it to the
   checkout.  Exactly how to maintain this information, is up to you.
   This might be a special directory in the project tree, populated
   and included into a commit by a pre-commit hook, an annotated tag
   attached to a commit after it has been recorded, `git notes`
   and so on.

Git does not support recording ownership information and permission bits
on the files it maintains.  The reason is that Git is not an archival
tool.  So if you need this info, you have to maintain/apply it yourself.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to