Re: [RFC/PATCHv2] git submodule split

[Eric Kidd <git@randomhacks.net>]

On Fri, Feb 13, 2009 at 11:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Eric Kidd <git@randomhacks.net> 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