[git] How to create a new submodule from existing submodule components?
Hi everyone,
As a first step of moving Boost.Assert out of Utility and into its own submodule, I've extracted its files (along with the history) into a test repository of mine:
https://github.com/pdimov/assert
If you consider its contents acceptable, please let me know what should
The release managers with help from Peter Dimov have been developing super-project workflow documentation. See https://svn.boost.org/trac/boost/wiki/SuperProjectWorkflow In that discussion, Peter wrote: the procedure
be for moving this repository into boostorg and making it a proper submodule.
I've take the liberty of moving this discussion to the main list for wider input on three questions. Please respond on this thread to the question asked in the subject line, and comment on the Proposed assert submodule and Super-project workflow on their threads. Thanks, --Beman
On 01/02/2014 10:19 AM, Beman Dawes wrote:
In that discussion, Peter wrote:
Hi everyone,
As a first step of moving Boost.Assert out of Utility and into its own submodule, I've extracted its files (along with the history) into a test repository of mine:
https://github.com/pdimov/assert
If you consider its contents acceptable, please let me know what should the procedure be for moving this repository into boostorg and making it a proper submodule.
I've take the liberty of moving this discussion to the main list for wider input on three questions. Please respond on this thread to the question asked in the subject line, and comment on the Proposed assert submodule and Super-project workflow on their threads.
Am I correct in understanding that the purpose of this thread is not to solicit instructions for how to extract a subtree with history into a separate git repository, but rather what consensus and requirements are to be applied to adding a new module and removing its functionality from another module? Is this not simply a matter of simultaneously applying existing processes for consenting to a major change in an existing library and accepting a new library into Boost? Peter
Peter A. Bigot wrote:
Am I correct in understanding that the purpose of this thread is not to solicit instructions for how to extract a subtree with history into a separate git repository, but rather what consensus and requirements are to be applied to adding a new module and removing its functionality from another module?
My original question was intended to be technical, not administrative. I wanted to know what are the technical steps that need to be undertaken for a new submodule to be added to the superproject, and whether the fact that the new submodule has files that collide with an existing submodule would complicate matters (because this will create a small window in which, say, boost/assert.hpp will be present in both Boost.Asset and Boost.Utility). A similar procedure will probably need to be performed each time a new library is added, so it might be worth it to have it documented. Since only release managers have access to the superproject, it will be one of them who will need to actually add the new module.
On Thu, Jan 2, 2014 at 11:52 AM, Peter A. Bigot
On 01/02/2014 10:19 AM, Beman Dawes wrote:
In that discussion, Peter wrote:
Hi everyone,
As a first step of moving Boost.Assert out of Utility and into its own submodule, I've extracted its files (along with the history) into a test repository of mine:
https://github.com/pdimov/assert
If you consider its contents acceptable, please let me know what should the procedure be for moving this repository into boostorg and making it a proper submodule.
I've take the liberty of moving this discussion to the main list for wider input on three questions. Please respond on this thread to the question asked in the subject line, and comment on the Proposed assert submodule and Super-project workflow on their threads.
Am I correct in understanding that the purpose of this thread is not to solicit instructions for how to extract a subtree with history into a separate git repository, but rather what consensus and requirements are to be applied to adding a new module and removing its functionality from another module?
I was interested in capturing instructions for extracting a subtree with history so they can be documented for future reference. Thanks, --Beman
Since I already have created the new submodule from the existing components, I may as well document the procedure I used here, to answer the question in the subject. The usual way to extract a portion of a Git repository, along with its history, is by using "git filter-branch". filter-branch, however, is reasonably easy to apply if what one needs to extract is contained in a subdirectory, which was not the case with Assert, where one needs to extract individual files. So I used "git log" instead to prepare a patch, as suggested in http://stackoverflow.com/questions/1365541/how-to-move-files-from-one-git-re... Specifically - and step by step - what I did in the original repository (libs/utility) was: git checkout master git log --pretty=email --patch-with-stat --reverse -- assert.html assert_test.cpp current_function.html current_function_test.cpp verify_test.cpp include/boost/assert.hpp include/boost/current_function.hpp
assert_master_patch.txt
git checkout develop git log --pretty=email --patch-with-stat --reverse -- assert.html assert_test.cpp current_function.html current_function_test.cpp verify_test.cpp include/boost/assert.hpp include/boost/current_function.hpp
assert_develop_patch.txt
Then, in the new (empty) repository: git checkout master git am < ../utility/assert_master_patch.txt git checkout develop git am < ../utility/assert_develop_patch.txt git checkout master git merge --no-ff develop git checkout develop git merge --no-ff master (For the merges, I take advantage of the fact that the files are identical in master and develop because I've ensured so while preparing the initial Boost.Utility merge point. For a repository in which master and develop have diverged and need to stay diverged in the new repository, the final two merges may need to be replaced by something else.) I then added test/Jamfile.v2 as a new file, as I decided that most of the history of the original Boost.Utility would not be relevant. (I could, alternatively, have imported it along with the other files and then deleted the references to everything but Assert as required.) (I prepared the initial empty repository by creating one via Github, cloning it, removing the README.md file, git push-ing the changes, then creating a "develop" branch via Github. There are other ways to do it. This one seemed easiest.)
On Thu, Jan 2, 2014 at 6:05 PM, Peter Dimov
Since I already have created the new submodule from the existing components, I may as well document the procedure I used here, to answer the question in the subject.
I've captured your procedure at https://svn.boost.org/trac/boost/wiki/NewLibByRefactor Comments or corrections appreciated! Thanks, --Beman
participants (3)
-
Beman Dawes
-
Peter A. Bigot
-
Peter Dimov