Re: [PATCH] git-submodule - Allow adding a submodule in-place

[Sven Verdoolaege <skimo@kotnet.org>]

On Mon, Mar 03, 2008 at 09:06:23PM -0500, Mark Levedahl wrote:
> @@ -9,17 +9,18 @@ git-submodule - Initialize, update or inspect submodules
>  SYNOPSIS
>  --------
>  [verse]
> -'git-submodule' [--quiet] add [-b branch] [--] <repository> [<path>]
> +'git-submodule' [--quiet] add [-b branch] [-r <remote>] [--] <repository> [<path>]
>  'git-submodule' [--quiet] status [--cached] [--] [<path>...]
> -'git-submodule' [--quiet] [init|update] [--] [<path>...]
> +'git-submodule' [--quiet] [init|update] [-r <remote>] [--] [<path>...]
>  
> @@ -55,6 +56,18 @@ OPTIONS
>  -b, --branch::
>  	Branch of repository to add as submodule.
>  
> +-r remote::
> +	Name of remote to use or define when working with relative submodules
> +	(i.e., submodules whose url is given relative to the top-level
> +	project). If this value is undefined, the top-level project's
> +	branch.<name>.remote is used, and if that is undefined the default
> +	"origin" is used. The remote will be defined in each relative
> +	submodule as needed by appending the relative url to the top level
> +	project's url. This option has no effect upon submodules defined
> +	using an absolute url: such project's are cloned using the default
> +	"origin," and are updated using the submodule's branch.<name>.remote
> +	machinery and defaulting to "origin."
> +

As has been noted by others, these changes don't belong in this commit.

As to the functionality actually provided by this patch,
I'm somewhat concerned with encouraging this kind of setup,
where the main (and only) copy of your subproject repo
is stored inside the working tree.

Ideally (for some at least), switching back to a commit
of the superproject from before the subproject was added
should remove the subproject from the working tree.
This means that the GIT_DIR of the subproject should be
stored somewhere under the GIT_DIR of the superproject.
There was some talk about doing this about a year ago,
but AFAIK, it hasn't gotten implemented yet.
It's easier to handle this when adding a subproject that
does not already exist in the tree.

Of course, if this feature would ever get implemented, then
it would also have to provide an upgrade path from the
current setup and that upgrade path would also handle your
case.  So this is not really an objection, but just a concern.

skimo