Modular boost directory structure
I am seeing at https://svn.boost.org/trac/boost/wiki/StartModDev that the modular Boost directory structure is: simple include boost simple twice.hpp test twice_test.cpp Jamfile.v2 doc // from the notes on the page index.html Is this the latest correct information ? I am asking because the original recommended structure was, as I understood it: simple boost simple twice.hpp libs simple test twice_test.cpp Jamfile.v2 doc html index.html I want to make sure I have this right before I modularize my sandbox libraries for git using the correct directory structure. BTW I have not been able to figure out how to add and move directories using git in a local copy. Instead I have just done so using the OS and git seems to figure it out but I have a feeling I have lost git history in doing so.
On 08/25/2013 10:20 PM, Edward Diener wrote:
I am seeing at https://svn.boost.org/trac/boost/wiki/StartModDev that the modular Boost directory structure is:
simple include boost simple twice.hpp test twice_test.cpp Jamfile.v2 doc // from the notes on the page index.html
Is this the latest correct information ?
looks about right too me, Dave will know for sure.
BTW I have not been able to figure out how to add and move directories using git in a local copy. Instead I have just done so using the OS and git seems to figure it out but I have a feeling I have lost git history in doing so.
As far as I know it does not mater much if you are using OS tools to move or rename files or you are using "git mv" command. Git will discover and track the change the same way - either way. Git does not really track the file rename by creating a record of any sort when you use "git mv", however it discover and trace file similarity between your commits, Later its history inspecting tools traces the fact that a file disappeared in a commit and an identical or similar file appeared in that same commit. The history tools will view this as a move. Sometimes I get paranoid that this may not be working perfectly, So it happens I do restructuring with file moves in separate commits pushed to the main repository without doing any file modifications in the same commit - just to help git to simpler trace the move later and follow file history across the moves. But that is probably just me being more careful than needed. HTH -- Bjørn
on Sun Aug 25 2013, Bjørn Roald
Sometimes I get paranoid that this may not be working perfectly, So it happens I do restructuring with file moves in separate commits pushed to the main repository without doing any file modifications in the same commit - just to help git to simpler trace the move later and follow file history across the moves. But that is probably just me being more careful than needed.
FWIW, I do the same thing. -- Dave Abrahams
Bjørn Roald
As far as I know it does not mater much if you are using OS tools to move or rename files or you are using "git mv" command. Git will discover and track the change the same way - either way.
Yes--it will even sometimes be over-zealous and consider a bona-fide new file be a copy with edits of another file. Often because the license blurb at the top provides enough "similarity" between the two files. PM
on Sun Aug 25 2013, Edward Diener
I am seeing at https://svn.boost.org/trac/boost/wiki/StartModDev
Note: I don't know how up-to-date that page is.
that the modular Boost directory structure is:
simple include boost simple twice.hpp test twice_test.cpp Jamfile.v2 doc // from the notes on the page index.html
Is this the latest correct information ?
Sure; look at any of the library-specific repositories under http://github.com/boostorg/ for examples.
I am asking because the original recommended structure was, as I understood it:
simple boost simple twice.hpp libs simple test twice_test.cpp Jamfile.v2 doc html index.html
Original? When was that recommended, and by whom?
I want to make sure I have this right before I modularize my sandbox libraries for git using the correct directory structure.
The best way to modularize sandbox libraries is to submit changes to the modularization rules described here: https://github.com/ryppl/Boost2Git/wiki
BTW I have not been able to figure out how to add and move directories using git in a local copy. Instead I have just done so using the OS and git seems to figure it out but I have a feeling I have lost git history in doing so.
You did it right; Git simply infers the move information. Git records snapshots and ancestry, and that's about it. Part of its philosophy is to be a "stupid content tracker" at its core. -- Dave Abrahams
On 8/25/2013 11:57 PM, Dave Abrahams wrote:
on Sun Aug 25 2013, Edward Diener
wrote: I am seeing at https://svn.boost.org/trac/boost/wiki/StartModDev
Note: I don't know how up-to-date that page is.
that the modular Boost directory structure is:
simple include boost simple twice.hpp test twice_test.cpp Jamfile.v2 doc // from the notes on the page index.html
Is this the latest correct information ?
Sure; look at any of the library-specific repositories under http://github.com/boostorg/ for examples.
I am asking because the original recommended structure was, as I understood it:
simple boost simple twice.hpp libs simple test twice_test.cpp Jamfile.v2 doc html index.html
Original? When was that recommended, and by whom?
I don't remember exactly but I am pretty sure the above was the original recommended structure ( perhaps minus the 'html-index.html' relation which is the way SVN has been AFAIK ) in one of the main topics for "Git and Modular Boost" on the Boost Wiki in the past. I believe that Beman Dawes wrote the original topics and I would not be surprised if he is the person who has been updating them since. I know I followed the above structure when I first moved my SVN sandbox libraries to git and GitHub. So I was a little surprised to see the latest recommended structure. I just wanted to make sure the latest structure is now the official way to go.
I want to make sure I have this right before I modularize my sandbox libraries for git using the correct directory structure.
The best way to modularize sandbox libraries is to submit changes to the modularization rules described here: https://github.com/ryppl/Boost2Git/wiki
Thanks for the link. Maybe a link to Ryppl on Github from somewhere on the Boost web sire would be appropriate.
BTW I have not been able to figure out how to add and move directories using git in a local copy. Instead I have just done so using the OS and git seems to figure it out but I have a feeling I have lost git history in doing so.
You did it right; Git simply infers the move information. Git records snapshots and ancestry, and that's about it. Part of its philosophy is to be a "stupid content tracker" at its core.
Feels odd coming from SVN but if it just works its fine with me.
On 08/27/2013 02:15 AM, Edward Diener wrote:
On 8/25/2013 11:57 PM, Dave Abrahams wrote:
BTW I have not been able to figure out how to add and move directories using git in a local copy. Instead I have just done so using the OS and git seems to figure it out but I have a feeling I have lost git history in doing so.
You did it right; Git simply infers the move information. Git records snapshots and ancestry, and that's about it. Part of its philosophy is to be a "stupid content tracker" at its core.
Feels odd coming from SVN but if it just works its fine with me.
I often find that the odd thing in git for new users is the concept of the index. It helps a-lot to spend a few minutes trying to grasp what the index is and how it can help you. If you attempt to ignore the index, as I feel many new git users do, it often lead to confusion with various git tools. If you use the index actively it becomes a great tool that help you in day to day work as it is intended to do. So what is the index: Simplest way to think of it is a staging ground between your files (working tree) and the next commit. Only the changes you have staged in index will be committed next time you do commit. You can move, add and remove files, whole directories, even individual changes within files (hunks) in the index based on selected current content in your working tree and the add and rm subcommands -- or any number of other tools and GUI that are based on them. Then when reading documentation, I think you should always pay attention when it talks about the index or staging, caching or tracking content. All these terms are related to the index. When I am using the following commands I always have the index in mind either to understand or to operate: git status git add <path> git add -u git mv <source> <destination> git mv <source> ... <destination directory> git rm <file>... git diff git diff --cashed git commit -a git commit Note that: git add -u git commit -a git mv are just convenience features that allow you to do things in fewer steps than just using bare bone git rm git add git commit When you commit, it is the state of the content changes in the index that matters, not the steps getting it into that state. E.g. there is no record in index that you used git mv, so you may just as well have done some OS mv combined with changing index with git add/rm. -- Bjørn
participants (4)
-
Bjørn Roald -
Dave Abrahams -
Edward Diener -
Petr Machata