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-07 07:18:55

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?