Re: [boost] [type_traits][core] modularisation and moving stuff about (again)

Subject: Re: [boost] [type_traits][core] modularisation and moving stuff about (again)
From: Bjørn Roald (bjorn.roald_at_[hidden])
Date: 2018-08-23 00:05:19

> On 22 Aug 2018, at 19:54, John Maddock via Boost <boost_at_[hidden]> wrote:
> 
> So radical suggestion - does type_traits just belong in core and lets be done with it?  What would happen to the file history if we moved it (can I still "git blame")?

For the record if you ever are going ahead with something like this. 

I think there are several options for keeping the history in Git so when moving stuff from one repository to another so git blame and friends still work. But some of them break historic references.  You will want to keep historic commits unchanged including their complete history with hashes intact.  Keeping commit hashes is essential for historic commits from the core repository in this case as they are referenced by the main boost repository and possibly elsewhere. Hence, any history-changing commands or scripted rebuilds should in general be avoided.  

I just tried out one method which you can try to see its it does what you want to do.  First call

git remote add -f type_traits ../type_traits

to make the type_traits repository tracked as a remote in the core repository, then
if you may need to call

git fetch —all 

before the merge below if you get the «this is something we cannot merge» error.

You then merge telling Git to ignore the fact that histories are not related.

git merge —allow-unrelated-histories type_traits/master

mac-bjorn:core bjorn$ git merge  --allow-unrelated-histories type_traits/master
Auto-merging test/is_same_test.cpp
CONFLICT (add/add): Merge conflict in test/is_same_test.cpp
Auto-merging test/Jamfile.v2
CONFLICT (add/add): Merge conflict in test/Jamfile.v2
Auto-merging meta/libraries.json
CONFLICT (add/add): Merge conflict in meta/libraries.json
Auto-merging index.html
CONFLICT (add/add): Merge conflict in index.html
Auto-merging doc/is_same.qbk
CONFLICT (add/add): Merge conflict in doc/is_same.qbk
Auto-merging doc/Jamfile.v2
CONFLICT (add/add): Merge conflict in doc/Jamfile.v2
Auto-merging appveyor.yml
CONFLICT (add/add): Merge conflict in appveyor.yml
Auto-merging .travis.yml
CONFLICT (add/add): Merge conflict in .travis.yml
Automatic merge failed; fix conflicts and then commit the result.

The result, after conflict resolution, should be histories from both repositories in one repository, with a merge commit at the top.  The only odd thing is that the histories do not have a common root.  There is no common ancestor for these histories, but that will likely not cause any problems as the merge commit create a common ancestor for later work.

I would have resolved the conflicts and committed, then based on the new commit started moving files without changing them into include/core (if that is what you want). 

In this case I think you will be fine moving files before you commit the merge if you just want a single commit. Note that in general, if you are moving files and making file content changes on the same file in one commit, then Git may have problems tracking that file move. I try to use a separate commit when I am moving files in Git to avoid this potential problem. However in 99 of 100 cases it will work regardless as it look for similar files that look like they are moved as well.

There may also be a good idea to make a single commit removing all files in the historic deprecated repository.  A notes file may be added to that commit to notify where the content has been moved and maybe why.  The repository cannot be removed from GitHub as it would break references, and thus this last commit in master may prevent some people getting lost.

Best regards,
—
Bjørn