Re: [boost] [git] Some headers are executable

Subject: Re: [boost] [git] Some headers are executable
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2014-01-08 04:13:56

On Wednesday 08 January 2014 02:32:55 Bjørn Roald wrote:
> On 01/07/2014 01:18 PM, Andrey Semashev wrote:
> 
> > So where do I have to report this issue so that the permissions are fixed
> > for all submodules?
> 
> Well, we need someone with write access to do it for all the respective
> repositories. If nobody pick it up, I think you should make a Trac issue.

I created a ticket for the "admin" submodule on GitHub.

https://github.com/boostorg/admin/issues/47

I think there needs to be a global solution since many libraries are involved.

> By the way, I see some inconsistency with what you reported as I get:
> 
> $ find boost -executable -type f
> boost/parameter.hpp
> boost/implicit_cast.hpp
> boost/indirect_reference.hpp
> boost/pointee.hpp

Yes, it seems some have been fixed since my first email.

> But this may all be caused by b2 headers generating symbolic links for
> folders on my system that causes find to ignore content of those folders
> without the -follow option, running:
> 
> $ find boost -follow -executable -type f
> 
> give a much longer list of files with executable bit set.
> 
> There is a number of change sets in SVN history that is about removal of
> SVN executable properties on headers, so there seems to have been an
> effort to remove the problem in SVN for the headers, The problem seems
> to to be cleaned up in SVN boost directory, only to get the problem
> re-created by git conversion  :-(

Yes, I tried to clean up at least the boost directory in SVN. After all, 
that's what you're supposed to install into the system.

> Fixing executable bit for the libs/*include headers is simple enough on
> POSIX systems in git as suggested in my previous post. So it is most
> likely no big loss that the conversion messed this up for the headers.
> 
> For libs files not in a libs/*/include folders many unlikely to be
> executable files have the executable property set and not removed in
> SVN. So it is a mess. Therefore I am not sure which of these may have
> the executable bit set on purpose. Even though the filenames suggests
> they do not need the executable bit, I would be careful with whole sale
> cleanup in libs based on filename extension only, Especially in test
> directories as there may be test cases depending on file modes. Thus I
> am reluctant to recommend exact actions to clean up in libs. Maybe the
> best approach is to identify odd files that shall have the bit set, then
> we can remove the bit from all other *.h *.hpp *.ipp *.png *.pdf *.html
> respectively for a start.

I'd safely add *.cpp, Jamfile*, *.jam, *.qbk, *.jpg, *.gif, *.css, *.rst, 
*.xml. Actually, it may be simpler to identify which files should be 
executable than not: *.sh, *.py, *.pl, *.bat, *.cmd.

> I suspect the root cause for most of the mess originating from SVN is
> that the executable bit is set by default from windows SVN clients to
> all new files.

This should have been avoided by autoprops in SVN config that were supposed to 
be set up by all developers. Obviously, not everyone did that and there were 
no commit hooks to prevent the mess.

I wish there was a way to enforce the correct metadata in git, whether by 
hooks or .gitattributes, so that the order is preserved once reached.