I was talking with @davetcoleman about the migration to the new single repository off-list, and I wanted to summarize some aspects of the migration we discussed.
Dave’s new moveit repository (https://github.com/ros-planning/moveit) was created by basically doing:
- move the contents of the old repository into a sub-folder in a single commit
- merged the branch from the old repository into the new repository
For each branch and repository being migrated into the new one. It’s a bit more complicated than that, see his migration script (https://github.com/davetcoleman/moveit_merge/blob/master/git_merge_moveit.sh) but that’s the bones of it.
This approach seems to be the most popular strategy on the Internet and it has the benefit that the commit hashes are preserved from the old repository to the new one. The downside is that since the files were moved in a commit it prevents GitHub from following the history of the file from before the move commit. Example:
There is another option, which is more complicated and invasive that avoids this issue. Basically you:
- rewrite every commit in the old repository’s branch as-if the code was always in a subdirectory
- merge the branch from the old repository into the new one
This has the advantage of not needing a “move commit” (so it has the same number of commits as the old repository), but has the disadvantage that all commits have different hashes in the new repository (because each commit was rewritten to have all content in a subfolder).
I did a quick test of this:
I don’t know what the moveit developers would prefer, but I offer my help if you’d like to pursue the rewrite history approach. Personally I don’t know which will work out better in the long run. It’s worth noting that the git log -- filename command has a --follow option that will follow moved files in most cases and GitHub might extend their history view to use that at some point.
The other item of discussion that I wanted to bring up was package versions and tags.
@davetcoleman you mentioned that you wanted to make the migration on Friday August 5th. Do you guys plan to do a catch up release of all the moveit packages in the new repository that day so that they have the same version number? Or will you wait until one of them needs to be released and release them all then?
With respect to tags, the options seem to be leave the old tags on the old repositories and only make new tags on the new repository or try to somehow migrate the tags, renaming them in the process to avoid collisions. I don’t know if there would be any benefit to migrating the tags, but I was curious to see what others think.
