On Fri, Feb 13, 2009 at 11:37 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Eric Kidd <git@xxxxxxxxxxxxxxx> writes: >> ... >> 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. Thank you for looking at this proposal! I think that the resulting repository is usable (though it could certainly be better). In particular, the following commands will always give you a working checkout: git checkout any-version git submodule update --init The unit tests for git-submodule-split.sh actually walk through the entire history and run 'git submodule update --init' at each revision. This works correctly because git-submodule-split creates the necessary .gitmodules entries for each revision, and includes the submodule.*.url value that you specify. Unfortunately, this means that whenever the submodule moves to a new location in the tree, 'git submodule --init' will actually have to clone it again. That's not a perfect situation, but it will work for reasonably small submodules. >> 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? Sounds good to me! I'd like to include the unit tests and some documentation, if that's OK. I'll let you know when the patch has been reviewed, and submit it for inclusion in contrib. >> 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. I realized that there's a problem with removing --force from filter-branch: The reflog doesn't contain backups of the rewritten tags. So I'm afraid --force and the refs/original/ directory will need to remain for now. (Any thoughts, Johannes?) >> 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 think so, although many (or most?) users will probably want to use '-- --all'. Thank you very much for your suggestions! Cheers, Eric -- 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
