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

When working in top-level project, it is useful to create a new submodule
as a git repo in a subdirectory, then add that submodule to top-level in
place.  This allows "git submodule add <intended url> subdir" to add the
existing subdir to the current project.  The presumption is the user will
later push / clone the subdir to the <intended url> so that future
submodule init / updates will work.

Absent this patch, "git submodule add" insists upon cloning the subdir
from a repository at the given url, which is fine for adding an existing
project in but less useful when adding a new submodule from scratch to an
existing project.  The former functionality remains, and the clone is
attempted if the subdir does not already exist as a valid git repo.

Signed-off-by: Mark Levedahl <redacted>
---
 Documentation/git-submodule.txt |   21 +++++++++++++---
 git-submodule.sh                |   50 +++++++++++++++++++++++---------------
 2 files changed, 47 insertions(+), 24 deletions(-)

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index e818e6e..85d7dd3 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt

@@ -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>...]
 
 
 COMMANDS
 --------
 add::
 	Add the given repository as a submodule at the given path
-	to the changeset to be committed next.  In particular, the
-	repository is cloned at the specified path, added to the
+	to the changeset to be committed next.  If path is a valid
+	repository within the project, it is added as is. Otherwise,
+	repository is cloned at the specified path. path is added to the
 	changeset and registered in .gitmodules.   If no path is
 	specified, the path is deduced from the repository specification.
 	If the repository url begins with ./ or ../, it is stored as

@@ -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."
+
 --cached::
 	Display the SHA-1 stored in the index, not the SHA-1 of the currently
 	checked out submodule commit. This option is only valid for the

diff --git a/git-submodule.sh b/git-submodule.sh
index 67d3224..7171cb6 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh

@@ -153,20 +153,6 @@ cmd_add()
 		usage
 	fi
 
-	case "$repo" in
-	./*|../*)
-		# dereference source url relative to parent's url
-		realrepo="$(resolve_relative_url $repo)" ;;
-	*)
-		# Turn the source into an absolute path if
-		# it is local
-		if base=$(get_repo_base "$repo"); then
-			repo="$base"
-		fi
-		realrepo=$repo
-		;;
-	esac
-
 	# Guess path from repo if not specified or strip trailing slashes
 	if test -z "$path"; then
 		path=$(echo "$repo" | sed -e 's|/*$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')

@@ -174,15 +160,39 @@ cmd_add()
 		path=$(echo "$path" | sed -e 's|/*$||')
 	fi
 
-	test -e "$path" &&
-	die "'$path' already exists"
-
 	git ls-files --error-unmatch "$path" > /dev/null 2>&1 &&
 	die "'$path' already exists in the index"
 
-	module_clone "$path" "$realrepo" || exit
-	(unset GIT_DIR; cd "$path" && git checkout -q ${branch:+-b "$branch" "origin/$branch"}) ||
-	die "Unable to checkout submodule '$path'"
+	# perhaps the path exists and is already a git repo, else clone it
+	if test -e "$path"
+	then
+		if test -d "$path/.git" &&
+		test "$(unset GIT_DIR; cd $path; git rev-parse --git-dir)" = ".git"
+		then
+			echo "Adding existing repo at '$path' to the index"
+		else
+			die "'$path' already exists and is not a valid git repo"
+		fi
+	else
+		case "$repo" in
+		./*|../*)
+			# dereference source url relative to parent's url
+			realrepo="$(resolve_relative_url $repo)" ;;
+		*)
+			# Turn the source into an absolute path if
+			# it is local
+			if base=$(get_repo_base "$repo"); then
+				repo="$base"
+			fi
+			realrepo=$repo
+			;;
+		esac
+
+		module_clone "$path" "$realrepo" || exit
+		(unset GIT_DIR; cd "$path" && git checkout -q ${branch:+-b "$branch" "origin/$branch"}) ||
+		die "Unable to checkout submodule '$path'"
+	fi
+
 	git add "$path" ||
 	die "Failed to add submodule '$path'"
 

-- 
1.5.4.3.438.g4c6f8

On Tue, Mar 4, 2008 at 10:06 AM, Mark Levedahl [off-list ref] wrote:

 +-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."
 +

Is this part necessary?

 --
 1.5.4.3.438.g4c6f8

-- 
Ping Yin

Mark Levedahl [off-list ref] writes:

When working in top-level project, it is useful to create a new submodule
as a git repo in a subdirectory, then add that submodule to top-level in
place.  This allows "git submodule add <intended url> subdir" to add the
existing subdir to the current project.  The presumption is the user will
later push / clone the subdir to the <intended url> so that future
submodule init / updates will work.

Absent this patch, "git submodule add" insists upon cloning the subdir
from a repository at the given url, which is fine for adding an existing
project in but less useful when adding a new submodule from scratch to an
existing project.  The former functionality remains, and the clone is
attempted if the subdir does not already exist as a valid git repo.

Signed-off-by: Mark Levedahl <redacted>

This is a very well written commit log message with an appropriate title,
and a convincing justification why this is a good idea.  Even I (who does
not heavily use submodules himself) can look at the patch and tell that
the existing check and die was too limiting to the users after reading
these two paragraphs.

I wish everybody wrote his commit log message like this.

+-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."
+

However, this part is not mentioned in the commit log message at all.

Is the enhancement advertised on the title line be useful _without_ this?

If so, this is a commit with two unrelated changes, and needs to be split
into two patches.  Also the other change that adds "-r remote" needs to be
explained and defended separately.

If not, the additional option should be described (what it does) justified
(why it is needed), and also there needs an explanation why this is an
integral part of the addition of this "add existing subdirectory" feature.

Yes, I _can_ guess that this option is related to your earlier f31a522
(git-submodule - allow a relative path as the subproject url).  Because
"submodule add" is used for setting up the initial .gitmodules entry for
the new submodule, you would need to give a clue to the command if you
want to set it up as a relative thing or an absolute thing, and you use
the relativeness of the URL parameter for that.  If you give a relative
path to the URL, however, you would need a way to pass in another piece of
information to let the command determine what it is relative to, and that
is the reason why this parameter exists.

But you _shouldn't_ be making me (or others, for that matter) wonder why
and justify it for you.  It should be explained in the commit log message.

On Mon, Mar 03, 2008 at 09:06:23PM -0500, Mark Levedahl wrote:

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

On Tue, Mar 4, 2008 at 2:09 AM, Junio C Hamano [off-list ref] wrote:

 However, this part is not mentioned in the commit log message at all.

...because the code to do the latter part is not a part of the patch,
and I failed to edit the documentation patch to remove that other
cruft. Will resend tonight when I have a connection that lets me send
patches.

Mark

When working in top-level project, it is useful to create a new submodule
as a git repo in a subdirectory, then add that submodule to top-level in
place.  This allows "git submodule add <intended url> subdir" to add the
existing subdir to the current project.  The presumption is the user will
later push / clone the subdir to the <intended url> so that future
submodule init / updates will work.

Absent this patch, "git submodule add" insists upon cloning the subdir
from a repository at the given url, which is fine for adding an existing
project in but less useful when adding a new submodule from scratch to an
existing project.  The former functionality remains, and the clone is
attempted if the subdir does not already exist as a valid git repo.

Signed-off-by: Mark Levedahl <redacted>
---

This eliminates the extraneous documentation of the previous patch that
was for functionality unrelated to this topic.

 Documentation/git-submodule.txt |    5 ++-
 git-submodule.sh                |   50 +++++++++++++++++++++++---------------
 2 files changed, 33 insertions(+), 22 deletions(-)

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index e818e6e..b4d0160 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt

@@ -18,8 +18,9 @@ COMMANDS
 --------
 add::
 	Add the given repository as a submodule at the given path
-	to the changeset to be committed next.  In particular, the
-	repository is cloned at the specified path, added to the
+	to the changeset to be committed next.  If path is a valid
+	repository within the project, it is added as is. Otherwise,
+	repository is cloned at the specified path. path is added to the
 	changeset and registered in .gitmodules.   If no path is
 	specified, the path is deduced from the repository specification.
 	If the repository url begins with ./ or ../, it is stored as

diff --git a/git-submodule.sh b/git-submodule.sh
index 67d3224..7171cb6 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh

@@ -153,20 +153,6 @@ cmd_add()
 		usage
 	fi

-	case "$repo" in
-	./*|../*)
-		# dereference source url relative to parent's url
-		realrepo="$(resolve_relative_url $repo)" ;;
-	*)
-		# Turn the source into an absolute path if
-		# it is local
-		if base=$(get_repo_base "$repo"); then
-			repo="$base"
-		fi
-		realrepo=$repo
-		;;
-	esac
-
 	# Guess path from repo if not specified or strip trailing slashes
 	if test -z "$path"; then
 		path=$(echo "$repo" | sed -e 's|/*$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')

@@ -174,15 +160,39 @@ cmd_add()
 		path=$(echo "$path" | sed -e 's|/*$||')
 	fi

-	test -e "$path" &&
-	die "'$path' already exists"
-
 	git ls-files --error-unmatch "$path" > /dev/null 2>&1 &&
 	die "'$path' already exists in the index"

-	module_clone "$path" "$realrepo" || exit
-	(unset GIT_DIR; cd "$path" && git checkout -q ${branch:+-b "$branch" "origin/$branch"}) ||
-	die "Unable to checkout submodule '$path'"
+	# perhaps the path exists and is already a git repo, else clone it
+	if test -e "$path"
+	then
+		if test -d "$path/.git" &&
+		test "$(unset GIT_DIR; cd $path; git rev-parse --git-dir)" = ".git"
+		then
+			echo "Adding existing repo at '$path' to the index"
+		else
+			die "'$path' already exists and is not a valid git repo"
+		fi
+	else
+		case "$repo" in
+		./*|../*)
+			# dereference source url relative to parent's url
+			realrepo="$(resolve_relative_url $repo)" ;;
+		*)
+			# Turn the source into an absolute path if
+			# it is local
+			if base=$(get_repo_base "$repo"); then
+				repo="$base"
+			fi
+			realrepo=$repo
+			;;
+		esac
+
+		module_clone "$path" "$realrepo" || exit
+		(unset GIT_DIR; cd "$path" && git checkout -q ${branch:+-b "$branch" "origin/$branch"}) ||
+		die "Unable to checkout submodule '$path'"
+	fi
+
 	git add "$path" ||
 	die "Failed to add submodule '$path'"

--

1.5.4.3.438.g4c6f8