1

my original git repo M had two sub-directories (A and B) which i've split off into separate git sub-modules a while back; repo M maintained its same directory structure, of course.... the original thinking was that A and B were relatively independent of each other....

after working this way for while, i'm realizing that A and B are much more coupled that i thought.... to that end, i want to now absorb sub-modules A and B back into M -- where they will once again become true sub-directories of the same name....

fortunately, i only have one working branch in A and B; and i only have about two months of commit history i'd like to preserve....

for sure, i could simply copy the latest contents of A and B back to their original sub-directories in M; and the changes would appear to like one big "squashed" commit....

my question, then, is how can perform this operation AND preserve the history currently sitting in sub-modules A and B ????

biosbob
  • 185
  • 1
  • 10
  • Does this answer your question? [Convert a git submodule to a regular directory and preserve the history in the main tree?](https://stackoverflow.com/questions/52224200/convert-a-git-submodule-to-a-regular-directory-and-preserve-the-history-in-the-m) – joshmeranda Jun 18 '22 at 14:48
  • that could certainly be part of the answer.... but what happens in the original repo already had sub-directories of the same names??? would the history imported from the sub-modules in retrospect look like i was working in a single repo all along??? – biosbob Jun 18 '22 at 14:53
  • I'm not sure what you mean by "already had sub directories of the same names," the submodule should already be referenced by their name and shuold not have a name collision. If there is you can just temporarily rename the colliding sub-directories until after the migration, and then go in to give everything their proper names – joshmeranda Jun 18 '22 at 15:56
  • I do not know if the history will reflect that you merged subdirectries but it will be maintained. Ideally it would make it clear that subdirectories were pulled in for the sake of transparancy, but again I don't know the specifics – joshmeranda Jun 18 '22 at 15:58
  • History, in any Git repository, *is* the set of commits in the repository (as found by branch names, tag names, and the like). There is nothing more or less to it. By adding commits to the repository, you add history. You can either add multiple commits, which adds multiple commits to history, or a single commit, which adds a single commit to history. – torek Jun 19 '22 at 08:48
  • Note in particular that there is no such thing as "file history". The commits *are* the history. If you ask `git log` to tell you about file `foo.ext`, what `git log` does is this: visit the most recent commit. Visit the earlier commit. Look at foo.ext in the two commits: did it change? If so, print the most recent commit's hash ID. Now move back one hop, and visit parent/child commits as before. Did foo.ext change? If so, print this commit (2nd most recent); if not, don't print it. Move back one hop... – torek Jun 19 '22 at 08:50
  • (This is simplified since when we hit a *merge* commit, we have *two or more* parents to visit. To explain how this works takes way more space than a comment provides, though. The important point here is not so much precisely how `git log` visits commits—though this matters—but the fact that it goes commit-by-commit, looking at parent/child pairs. The commits *are* the history.) – torek Jun 19 '22 at 08:51
  • Does this answer your question? [How to un-submodule a Git submodule?](https://stackoverflow.com/questions/1759587/how-to-un-submodule-a-git-submodule) – Mark Rotteveel Jun 20 '22 at 10:24

0 Answers0