Re: [RFC/PATCHv2] git submodule split
- From
- Eric Kidd <git@randomhacks.net>
- Date
- Feb 14, 2009, 14:11 UTC
- 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