Looking for a way to reimport modifications made in a repository (whose root directory was modified using git filter-branch to remove unneeded top level folders) into its ancestor, I luckily fell on the git subdir.
Here is an extract of the README.md to give you an idea of what it is :
Compared to other approaches (git-submodule, git-subtree), git-subdir:
- Embeds the actual content, not just a reference (like git-subtree and unlike git-submodule).
- Does not store any metadata, and there's no requirement for the imported commits to stay intact. Rebase, amend and filter-branch to your heart's content.
- Does not try to map commits across repositories. It focuses on the commits that need to be imported or exported at the moment, and does not care about historical commits.
- In fact, there is no persistent state at all (aside from some command-line options automatically saved as defaults for later).
- Will happily pick up the results of git-subtree, subtree merge or any other way of syncing folders. In fact, even if you have copied the subfolder via drag'n'drop or cp -r, you can still use git-subdir to sync changes.
- Syncs both ways: you can commit into the embedded repository and then import the commits into the master one, or you can commit in the master repository and then export the commits into the embedded one. In fact, you can alternate between the two approaches.
To put it simply, the idea of git-subdir is that, conceptually, we want an approach similar to cherry-picking rather than the strict semantics of normal merge/rebase.
I have tested it two times for now and it seems to work perfectly.
Hope that could inspire someone.