Boost logo

Boost :

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



Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk