git filter-branch --subdirectory-filter is really useful and easy to use. It's a commonly used step as part of moving a directory from one repo to another. It lets you move a subdirectory to the root of the repo.
I've found that, when moving directories between repos, I often want to do a task that is very similar to --subdirectory-filter but not quite the same — I want to put the subdirectory under a prefix (and maybe in this case the "subdirectory" should just be the entire repo).
Searching the web for <git move directory to new repository> shows that wanting to do something like this is pretty common.
It's certainly possible to do this with --index-filter or --tree-filter, and the man page even has an example:
git filter-branch --index-filter \
'git ls-files -s | sed "s-\t\"*-&newsubdir/-" |
GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
git update-index --index-info &&
mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' HEADBut gosh, this is just a pain to write.
I'd like to add direct support to git filter-branch for having a non-root target for subdirectory-filter.
I have a couple questions:
(1) What interface should this have? I'd lean towards having this just be part of --subdirectory-filter as a separate option --subdirectory-target-prefix. For the "move root to subdir" you maybe would have to type --subdirectory-filter=/, or maybe empty --subdirectory-filter combined with --subdirectory-target-prefix does the trick.
Alternatively, it could be a new filter type specific to moving subdirectories around, but I don't know that that makes sense.
(2) The way I'd imagine I would implement this would be to replace the current `git read-tree -i -m $commit:"$filter_subdir"` with `git read-tree --empty && git read-tree --prefix=PREFIX/ $commit:"$filter_subdir"`. --prefix is incompatible with -m, and I don't really understand the importance of the stat reuse that is done by `-i -m` single-tree merge. Is it OK to just drop the -i -m?
--dave