Take a project with, say, the executable source in the main repository M and dependent libraries in several sub modules S1, S2, etc. The decision is made that some code in the executable should be migrated to the library in submodule S1 to make it generally accessible to other projects. We branch both the main repository and the submodule, and step 1 of the migration process is to simply move N files from a directory in M to an a particular directory (with different-looking paths) in S1. The naive way to do this is to simply git rm the files from M, move them to their new directory in S1, cd to the submodule, and git add them. The problem of course is that all history is lost for these files. This is not a huge issue because I don’t think for example that pull-merge would track changes from the files in M to their new home in S1, but it would be nice, to be able to recover as a diff the changes that were made to the files to adapt to their new location and other necessary changes surrounding the refactor.
So that’s my question: is there a better way to accomplish the file migration from M to S1 than a simple rm-and-add, such that at least the history on the files is retained. If it were within M, of course, one would simply use git-mv. I have seen some formula for moving files between arbitrary repositories, but A, I find them nearly impossible to follow, and B, I was hoping perhaps the managed relationship between main and submodule would make it easier or more elegant to accomplish. If the answer is that for these purposes, M and S1 are just two arbitrary distinct repositories, perhaps someone here could lay out the steps with explanation in a way that is better than I have seen done elsewhere. This is pretty much actually a task I’m looking at now, so any relevant feedback would be appreciated.
Edit: it was reasonably suggested that this is a dup of Git: Moving files into an existing submodule. It seems to be true and that doesn’t surprise me that this has been raised before, but the answer is fairly terse for a reader with fairly rudimentary understanding of git. I was hoping for a break-down of the steps with a fuller description of the commands involved.
Edit2: it occurs to me that the reason the answer for the supposed dup (and for other similar questions and answers) are not working for me is two-fold. On the one hand, it took reading through all of them a couple of times to get the sense of what is being done, just because I need to deepen my model of what is going on git. That's on me. But having done that and now understanding what is happening with these split-and-merge approaches, I realize that the problem I'm trying to solve runs a little deeper - so deep, in fact, that I'm beginning to realize it's probably a unicorn that git is not able to deliver.
When you have a monolithic repository - no submodules, you can move a file with a git mv, and it gives the system more information than simply removing from one location and adding to another. It preserves the history, but I believe it also allows git to track changes that are made in the moved files, regardless of where they are in other local repositories. So if I move my files in a branch, and others modify the files in their own view of the files and commit and push those changes and merge them to the main branch, then I believe git has enough accounting information that when I pull those changes, they get merged to the files in their new location in my view of the repository. This is a much more greater value-add (in my opinion) than just preserving history. If I remove files from the main repository and add them to the submodule, they will have no history in their new location, but the history from their life in the old location will still be retrievable via the "ghosts" of the deleted files. Inconvenient, but not catastrophic. But if there were a way to manage changes from other developers' views and have them directed to the files as they exist in the submodule, that would be amazing. So amazing that seems beyond the scope of what git could do. To summarize, I think I was looking for a magic 'git mv' that could work across repositories, and now that I think about it, I doubt such a thing exists.
