Eric Kidd <git@xxxxxxxxxxxxxxx> writes: > Proposed usage: > git submodule split [--url submodule_repo_url] submodule_dir \ > [alternate_dir...] > > Replace submodule_dir with a newly-created submodule, keeping all the > history of submodule_dir. This command also rewrites each commit in the > current repository's history to include the correct revision of > sumodule_dir and the appropriate .gitmodules entries. > > If the submodule has moved around the source tree, specify one or more > values for alternate_dir. To specify the URL of the newly created > repository (for use in .gitmodules), use the --url parameter. Unfortunately, I do not think we have designed fully (nor implemented at all) behaviour to check out different points of history that has the same submodule moved around in the superproject tree. There were several unconcluded discussions done in the past (and I admit I participated in a few of them), but it may be hard to use the resulting repository out of this tool. I am not saying the split-submodule-history tool is bad in any way, of course. I'm just saying that the "git submodule" side needs to be updated to support such a history better; otherwise the tool's output won't be usable effectively. You may want to Cc "submodule" people in the discussion. > Johannes Schindelin provided extensive help with the UI and > implementation of this command (but has not yet reviewed the code). > > Cc: Junio C Hamano <gitster@xxxxxxxxx> > Cc: Johannes Schindelin <johannes.schindelin@xxxxxx> Please drop these two lines. They belong to e-mail headers. > Open questions: > > 1) Right now, this command is actually git-submodule-split.sh. Should > I include this code directly into git-submodule.sh, or move it > to git-submodule--split.sh and hook it into git-submodule.sh? How about in contrib/ somewhere? > 2) Should I implement a --force flag based on filter-branch? Johannes > Schindelin has suggested that it might be better to remove the > --force flag from filter-branch and just rely on the reflog to keep > backups. Sounds sensible to me, but I do not have strong feeling about this either way. > 4) We're obviously going to need to support revision arguments other > than --all (which is what we currently pass to filter-branch). Should > we default to the current branch only, or to --all? Matching what filter-branch defaults to would be the most natural, wouldn't it? I didn't look at the patch, though. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
