On Saturday 07 December 2013 20:09:36 Bjørn Roald wrote:

On 12/07/2013 01:33 PM, Andrey Semashev wrote:

...

Hi,

I've just checked out git and ran b2 headers and noticed that some headers have executable attribute. For example:

$ find boost -executable -type f boost/pointee.hpp boost/assign.hpp boost/graph/vf2_sub_graph_iso.hpp boost/indirect_reference.hpp boost/parameter.hpp boost/detail/indirect_traits.hpp boost/detail/is_xxx.hpp boost/range.hpp

This was not the case with svn. Is this the result of the transition? Can this be fixed?

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.

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:

make hotfix branches --------------------

git submodule foreach 'git checkout master' git submodule foreach 'git checkout -b hotfix/remove-exe-bits'

Do the edits needed -------------------

find libs/*/include/boost -type f | xargs ls -l | grep rwx | \ sed 's%^.*libs/%libs/%' | xargs chmod 664

.. or any other boost wide changes you need done

Check what you got -- only for the faint hearted ---------------------------------------------- git submodule foreach git diff

If you need to roll back roll back: git submodule foreach 'git reset --hard origin/master || :'

the '|| :' at the end of the command is to make foreach ignore and continue if the command fail in a submodule.

Commit it and merge to master ----------------------------- git submodule foreach 'git commit -am "remove exec bit on headers" || :' git submodule foreach 'git checkout master' git submodule foreach 'git merge --no-ff hotfix/remove-exe-bits || :'

the --no-ff ensure you get a merge commit in master, not really needed for this simple fix I think - but its the gitflow way.

Push it back to github -- only for those who can ------------------------------------------------ git submodule foreach 'git push || :'

Put hotfix into develop, ------------------- normally it should be the same same as for master, but... CAUTION!!! Until develop and master is better sync'ed I would not merge hotfixes into develop as prescribed in git flow.

I really think everyone should get a resent merge between develop and master in the most sensible place for their library and put all long-running development into a feature branch, or five of them if needed.

The develop branch should be more for the next thing you plan to put in master, not long running work.

cherry-pick may be much better than merge for this getting this hotfix into develop, but I am not sure how well this works in submodule foreach though. In any case, the conflicts are not unlikely to be messy even with cherry-pick. It would be something like:

git submodule foreach 'git checkout develop' git submodule foreach 'git cherry-pick hotfix/remove-exe-bits || :'

Then fix any merge issues or roll back.

You can always make the changes directly in develop after checkout: find libs/*/include/boost -type f | xargs ls -l | grep rwx | \ sed 's%^.*libs/%libs/%' | xargs chmod 664 git submodule foreach 'git commit -am "remove exec bit on headers" || :' git submodule foreach 'git push || :' # only for those who can

Clean up: --------- After you are done, just get rid of the hotfix branch, it is just a local reference anyway, the shared commits do not go away.

git submodule foreach 'git branch -d hotfix/remove-exe-bits || :'

for reference: http://nvie.com/posts/a-successful-git-branching-model/

So where do I have to report this issue so that the permissions are fixed for all submodules?

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.