...

Although I would gladly accept a move of boost/detail/endian.hpp to Predef (since I'm the sole author at this point). A much nicer solution would be to change boost/mpl/string.hpp to use the non-detail endian macros of Predef. As ti gets us closer to removing detail/endian.hpp entirely.

Also possible. Moving the header will however also "fix" (as in, remove their dependency on Detail) its other uses:

Inclusion report for (in module detail):

from math: from mpl: from multiprecision: from serialization: from spirit:

We could also fix them all "properly", it's just more work and less immediate.

+1, assuming all the necessary predef code is in release? John.

Peter Dimov wrote:

Rene Rivera wrote:

...

Although I would gladly accept a move of boost/detail/endian.hpp to Predef (since I'm the sole author at this point). A much nicer solution would be to change boost/mpl/string.hpp to use the non-detail endian macros of Predef. As ti gets us closer to removing detail/endian.hpp entirely.

Also possible. Moving the header will however also "fix" (as in, remove their dependency on Detail) its other uses:

Inclusion report for (in module detail):

from math: from mpl: from multiprecision: from serialization: from spirit:

We could also fix them all "properly", it's just more work and less immediate.

Needless to say, I'm in favour of anything (sensible) that leads to reduced dependencies. :-) -Julian

On Wed, Jun 4, 2014 at 8:25 PM, Peter Dimov wrote:

Rene Rivera wrote:

...

Although I would gladly accept a move of boost/detail/endian.hpp to Predef (since I'm the sole author at this point). A much nicer solution would be to change boost/mpl/string.hpp to use the non-detail endian macros of Predef. As ti gets us closer to removing detail/endian.hpp entirely.

I've changed mpl/string.hpp to use Predef directly, but I still think that we should move detail/endian.hpp to Predef, as this is where it rightfully belongs.

OK.. Could someone send me the pull request? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

On Thu, Jun 5, 2014 at 9:55 AM, Peter Dimov wrote:

Rene Rivera wrote:

...

...

I've changed mpl/string.hpp to use Predef directly, but I still think >

On Wed, Jun 4, 2014 at 8:25 PM, Peter Dimov wrote: that we should move detail/endian.hpp to Predef, as this is where it > rightfully belongs.

...

OK.. Could someone send me the pull request?

I've taken the liberty of just moving it. predef:master/release differed by just one commit and detail/endian.hpp is the same in both branches, so this should not create any merge problems.

I can't merge from develop to master now :-( -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

OK, I tried again and it worked. No idea what happened on my first try. Git mysteries :-\ On Thu, Jun 5, 2014 at 10:11 AM, Peter Dimov wrote:

Rene Rivera wrote:

I can't merge from develop to master now :-(

...

Why not? I can:

C:\Projects\boost-git\boost\libs\predef>git status # On branch master nothing to commit, working directory clean

C:\Projects\boost-git\boost\libs\predef>git pull Already up-to-date.

C:\Projects\boost-git\boost\libs\predef>git merge develop Auto-merging build.jam Merge made by the 'recursive' strategy. jamroot.jam => build.jam | 3 +-- test/.gitignore | 1 + 2 files changed, 2 insertions(+), 2 deletions(-) rename jamroot.jam => build.jam (81%)

C:\Projects\boost-git\boost\libs\predef>git status # On branch master # Your branch is ahead of 'origin/master' by 18 commits. # (use "git push" to publish your local commits) # nothing to commit, working directory clean

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

-- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Rene Rivera wrote:

OK, it's the automatic merge on github I can no longer do. Two things:

It was the latest commit, "Reverting (c) to human author", that created the merge conflict.

1. In the future please do not fast-forward history on master branches. It messes up the natural flow of the git history.

I didn't fast-forward history, if by that you mean "git merge develop" - I moved the file via git log / git am in both branches per https://svn.boost.org/trac/boost/wiki/NewLibByRefactor Most of the history of this file is from the SVN and the transition doesn't preserve any merge points, so the two branches appear completely separate, even though the commits turn out to be actually identical in this case.

2. Could you do me the favor of merging on the command line?

Done. I had to cherry-pick the latest develop commit first though, to avoid the conflict. C:\Projects\boost-git\boost\libs\predef>git cherry-pick develop [master bcdaa18] Reverting (c) to human author. Author: Rene Rivera 1 file changed, 1 insertion(+), 1 deletion(-) C:\Projects\boost-git\boost\libs\predef>git status # On branch master # Your branch is ahead of 'origin/master' by 1 commit. # (use "git push" to publish your local commits) # nothing to commit, working directory clean C:\Projects\boost-git\boost\libs\predef>git merge --no-ff develop Auto-merging build.jam Merge made by the 'recursive' strategy. jamroot.jam => build.jam | 3 +-- test/.gitignore | 1 + 2 files changed, 2 insertions(+), 2 deletions(-) rename jamroot.jam => build.jam (81%) C:\Projects\boost-git\boost\libs\predef>git status # On branch master # Your branch is ahead of 'origin/master' by 20 commits. # (use "git push" to publish your local commits) # nothing to commit, working directory clean C:\Projects\boost-git\boost\libs\predef>git diff master..develop C:\Projects\boost-git\boost\libs\predef>git push Counting objects: 5, done. Delta compression using up to 8 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 481 bytes | 0 bytes/s, done. Total 3 (delta 1), reused 0 (delta 0) To https://github.com/boostorg/predef.git 4dd9dc7..3902dd7 master -> master

Daniel James wrote:

But I wouldn't transfer the history, it just creates a load of noise that gets in the way. And it isn't at all clear what happened.

Well that certainly would be much easier. In principle, you could do "git log --follow -- file" and see the history. That's basically the only thing that moving the history gives us. And I suspect that it might be convenient for people who like to right-click on things and choose "Log" from the menu. It does create a lot of noise in "git log" though.

If someone wants to see the old history, it's easy enough to check the original repo.

Not if you didn't know what the original repo was. :-)

On 6 June 2014 00:42, Daniel James wrote:

On 5 June 2014 17:01, Peter Dimov wrote:

...

Most of the history of this file is from the SVN and the transition doesn't preserve any merge points, so the two branches appear completely separate, even though the commits turn out to be actually identical in this case.

That's because 'git log' includes the commits from both branches when they're merged.

I think a better way to do this is to create a copy of the repo, use 'git filter-branch' to reduce the history to the files you want, then fetch the appropriate branches into the destination, and merge the branch into your tree. There's an example of using 'git filter-branch' at http://stackoverflow.com/a/6006679/2434.

Daniel James wrote:

On 2 June 2014 22:04, Peter Dimov wrote:

...

boost/iterator.hpp can be moved to core in all its former glory (and probably replaced by a one-liner, using std::iterator.)

Or other libraries could be changed to use std::iterator. Is it worth adding an obsolete header to core?

Moving it is the safer choice; if it turns out that we do need to workaround some uses of std::iterator after all, the changes will be isolated to a single place. But either way is fine with me. Here's the report on boost/iterator.hpp, if we choose the second option: Inclusion report for (in module iterator): from circular_buffer: from concept_check: from filesystem: from geometry: from graph: from multi_array: from spirit: from unordered: from utility: