Re: [PATCH] git-submodule - Allow adding a submodule in-place
From: Sven Verdoolaege <hidden>
Date: 2016-06-15 22:44:20
On Mon, Mar 03, 2008 at 09:06:23PM -0500, Mark Levedahl wrote:
quoted hunk ↗ jump to hunk
@@ -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