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

Subject: Re: [boost] [git] Some headers are executable
From: Bjørn Roald (bjorn_at_[hidden])
Date: 2014-01-07 20:32:55

On 01/07/2014 01:18 PM, Andrey Semashev wrote:
> On Saturday 07 December 2013 20:09:36 Bjørn Roald wrote:
>> On 12/07/2013 01:33 PM, Andrey Semashev wrote:

snip...

>> Yes, just change them and and do
>>
>> git commit -a
>>
>> The access bits are internally in a git repository part of the git tree
>> objects which hold filenames,their sha1 and access bits for each file
>> and subdirectory in a single directory. So they are preserved as you
>> check them in at each commit.
>
> I assume, this will be a local change, right? I'd like the files to have the
> right permissions in the upstream.

correct, that require a git push by someone with write access to the 
upstream boostorg repositories on GitHub or alternatively a GitHub Pull 
Request.

>> Someone with the needed write access to all boostorg repositories on
>> Github could do it for everyone. It could be done as a modified version
>> of gitflow hotfix using submodules, something like:

snip.. suggested git commands ..snip

> 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.

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

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  :-(

I did some tests comparing executable bits from a working directory from 
svn trunk against my modular boost working directory.  Comparing the 
attached file listings of files with executable bit set in the boost, 
libs, and tools directories respectively indicate that the problem is 
more widespread than only header files in boost folder.

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.

The tools directory seems to be clean in SVN based on filenames with 
executable bit set, none seems to be clearly out of place.  However in 
git the following suspects are added:

tools/quickbook/doc/html/images/extra/katepart/boost.hs.logo.png
tools/quickbook/extra/katepart/syntax/boost_hs_boost.xml
tools/quickbook/extra/katepart/syntax/boost_hs_cpp.xml
tools/quickbook/extra/katepart/syntax/boost_hs_quickbook.xml
tools/quickbook/extra/katepart/syntax/boost_hs_std.xml

Hence the tools directory seems to be trivial to fix as it only affect a 
few files in tools/quickbook affected.

The doc directory have 3 suspects that seems to be added by conversion:

doc/html/images/prev_disabled.png
doc/html/images/up_disabled.png
doc/html/images/next_disabled.png

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.  I am not sure how to avoid similar issues with windows 
git clients. Here is a related discussion that may provide hints if this 
is a problem in git on windows (first google hit)

https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/0EdNev3NNsw 

This discussion also indicate one method to set executable git file mode 
in windows for those that would need that, I repeat it here without 
testing it:
$ git update-index --chmod=-x <file>...
$ git checkout -- <file>...
$ GIT_EDITOR=: git commit --amend

1) sets the mode in the index
2) syncs the updated mode back to the working copy
3) amends the existing commit w/o bothering you with an editor

For those interested, see attached files for sorted listings of boost 
files with executable bit set.  Diff the svn v.s. git file pairs to see 
changes do to git conversion and restructuring, I recommend using a good 
graphical diff tool like meld (http://meldmerge.org/) for this.

--
Bjørn