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/0EdNev3N... 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