Re: [RFC/PATCHv2] git submodule split

[Junio C Hamano <gitster@pobox.com>]

Eric Kidd <git@randomhacks.net> 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@pobox.com>
> Cc: Johannes Schindelin <johannes.schindelin@gmx.de>

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.