Re: git-archive and tar options

[Neal Kreitzinger <nkreitzinger@gmail.com>]

On 7/19/2011 12:56 PM, René Scharfe wrote:
> Am 19.07.2011 02:12, schrieb Neal Kreitzinger:
>> On 7/18/2011 3:50 PM, René Scharfe wrote:
>>> Am 18.07.2011 20:13, schrieb Neal Kreitzinger:
>>>> However, the permissions also need to change to 777 and tar --mode would
>>>> not effect this in combination with --catenation or -x.  Is there a way
>>>> I can change the permissions without having to untar->chmod->retar, and
>>>> without having to use a non-bare repo as an intermediary?
>>> You can use the configuration setting tar.umask to affect the
>>> permissions of the archive entries.  Set it to 0 to pass the permission
>>> bits from the repo unchanged.
>>>
>> The permissions in my repo are 775 and 664 and I want to change them to
>> 777.
> Git doesn't store all permission bits.  If a file is marked as
> executable then you get 777, otherwise 666 -- minus the umask, which is
> 0002 by default.  So in order to achive rwx permissions for all in the
> archive, you need to A) mark the files as executable in the repository
> and B) set tar.umask to 0 to get allow the world to write.
>
> However, what's the reason for requiring this lack of access control?
> Why o+w?
tar.umask worked.  Thank you for explaining how the permissions work in 
this context.  I now see that 775 and 664 would work for the apache 
component and for executing our binaries.  Thanks for pointing this 
out.  However, another element of our application is a proprietary 
runtime that runs on top of linux and runs our core binaries.  This 
allows us to store our binaries in git and deploy them directly on the 
customer server from git (via git-archive).  That runtime needs o+w in 
order to update the 'last run date' in the binary which is critical to 
our troubleshooting in the field.  o+w is needed because the user's 
runtime instance runs with user permissions when executed from a linux 
command line terminal and our users are not setup in the same group as 
the binaries.  Therefore, with tar.umask = 0000 I can deploy 777 and 666 
permissions and everything will work.

I suppose I could write a script to change the tar.umask entry to 0000 
only when running git-archive for the binary portion, and use tar.umask 
0002 when extracting the other portions.  I could also change our setup 
to put the users and the runmodules in the same group and use tar.umask 
0002 across the board.  These would be more correct than the chmod 777 
shotgun that we currently use to blast away our permissions problems.

git-archive is a "quick" solution to our immediate deployment needs.  
Eventually, I plan on using git on the source and target machines as the 
core mechanism to "promote to production" (ie. deploy to customer 
servers).  It looks like others are using git for deployment also.  In 
my previous shops which used other VCS's on minicomputers and 
mainframes, "promote to production" meant the universal run path for all 
users (and especially for productional data transactions) on that 
central machine.  In my current shop (my first linux shop) we have 
multiple concurrent versions of production on a multitude of 
productional machines and even concurrently on an individual 
productional machine in some cases.  The main reason we chose git is 
because it is the only VCS that can handle this.

v/r,
neal