How can I force git to recognize a change change in file modes?

Hi,

I checked in a slew of scripts, only to realize that the file
permissions were too open (I want them to be chmod 700, not chmod
755).  Somehow I thought that git was tracking those permission bits,
but simply using "chmod 700 <fileset>; git add <fileset>" did not add
the change of file modes, well, at least git status output doesn't
show it. Is there a way to do this?

Thanks,
Brent

Hi,

I checked in a slew of scripts, only to realize that the file
permissions were too open (I want them to be chmod 700, not chmod
755).  Somehow I thought that git was tracking those permission bits,
but simply using "chmod 700 <fileset>; git add <fileset>" did not add
the change of file modes, well, at least git status output doesn't
show it. Is there a way to do this?

git doesn't track permissions quite that closely; all it remembers is
whether the file should be executable or not.

-Jan

* Brent Goodrick [off-list ref] [09-02-28 02:17]:

I checked in a slew of scripts, only to realize that the file
permissions were too open (I want them to be chmod 700, not chmod
755).  Somehow I thought that git was tracking those permission bits,
but simply using "chmod 700 <fileset>; git add <fileset>" did not add
the change of file modes, well, at least git status output doesn't
show it. Is there a way to do this?

Git does only track the executable bit.

git doesn't track permissions quite that closely; all it remembers is
whether the file should be executable or not.

Thanks Jan.  Was this choice made due to the conditional coding
required to track the permission bits content between *NIX and
non-*NIX platform(s)?

bg

On Sat, Feb 28, 2009 at 11:24 AM, Brent Goodrick [off-list ref] wrote:

Thanks Jan.  Was this choice made due to the conditional coding
required to track the permission bits content between *NIX and
non-*NIX platform(s)?

The short answer is: because Git was designed to track content. The
long answer is more complicated. Here's one of the more useful past
discussions:

http://thread.gmane.org/gmane.comp.version-control.git/91783

I'm sure you can find others by searching the git list for "metadata".

j.

The short answer is: because Git was designed to track content. The
long answer is more complicated. Here's one of the more useful past
discussions:

http://thread.gmane.org/gmane.comp.version-control.git/91783

I'm sure you can find others by searching the git list for "metadata".

I read that thread you showed above. Sounds like a big squirmy
can-o-worms, and I see that thread died on the vine because of it. :)

All I want to do in my case is just chmod 700 a bunch of scripts after
they are checked out or updated.  I'll need to re-read the git-hooks
man page more closely.

Thanks for your help!
bg

Brent Goodrick wrote:

All I want to do in my case is just chmod 700 a bunch of scripts
after they are checked out or updated.  I'll need to re-read the
git-hooks man page more closely.

You may want to check contrib/hooks/setgitperms.perl as well, if you
haven't seen it already.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Problems are opportunity in work clothes.

On Sat, Feb 28, 2009 at 10:34 AM, Todd Zullinger [off-list ref] wrote:

You may want to check contrib/hooks/setgitperms.perl as well, if you
haven't seen it already.

Yes I did see that. I'll be varying that approach a bit since I won't
need to preserve perm bits before and after the git operation, but
just force them to be a specific value all the time after checkout and
update.

bg