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"' HEAD
But 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
