From: Eric Kidd <git@randomhacks.net>
Date: Sat, 14 Feb 2009 14:11:16 GMT
Subject: Re: [RFC/PATCHv2] git submodule split
Message-ID: <431341160902140611x69a915e6lc3ee482f1ca66dc8@mail.gmail.com>
In-Reply-To: <alpine.DEB.1.00.0902141245080.10279@pacific.mpi-cbg.de>

On Sat, Feb 14, 2009 at 6:46 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> As I said to Eric already, I would like this to be part of git-submodule
> proper, as I expect a lot of people needing it.

I'm happy to do whatever people want. :-) Even if this goes into
contrib/, I want to include everything a regular git command would
have: unit tests, a man page, portable sh code, etc. And I want to
make 'git-submodule-split' useful to as many people as possible.

Which brings me to a design question: Would 'git-submodule-split' be
useful to more people if it were actually two commands?

1) git submodule split: Create the new submodule, update the working
copy, but do not change any history in the super-project. This would
be useful for existing projects that don't want to rewrite existing
commits, but which want to spin off a submodule.

2) git submodule split --rewrite-history: Update the history of the
project to use the rewritten submodule. This would be most useful when
migrating repositories to git.

I've already implemented (2), but frankly, it feels like a special
case of a larger command. It would be very easy to implement (1) and
make it the default.

Cheers,
Eric