[PATCH 1/2] git-submodule.sh: fix filename in comment.

Signed-off-by: Michał Górny <redacted>
---
 git-submodule.sh |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/git-submodule.sh b/git-submodule.sh
index 5c61ae2..fbf2faf 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh

@@ -1,6 +1,6 @@
 #!/bin/sh
 #
-# git-submodules.sh: add, init, update or list git submodules
+# git-submodule.sh: add, init, update or list git submodules
 #
 # Copyright (c) 2007 Lars Hjemli
 

-- 
1.7.10.2

Add an 'rm' command to git-submodule which provides means to
(semi-)easily remove git submodules.

Signed-off-by: Michał Górny <redacted>
---
Right now, it requires the submodule checkout to be removed manually
first (so it does not remove unstaged commits), and just removes
the index entry and module information from config.

I based it on 'cmd_add' code trying to preserve the original coding
standards.

 Documentation/git-submodule.txt |   12 +++++++
 git-submodule.sh                |   68 ++++++++++++++++++++++++++++++++++++++-
 2 files changed, 79 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index fbbbcb2..293c1bf 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt

@@ -11,6 +11,7 @@ SYNOPSIS
 [verse]
 'git submodule' [--quiet] add [-b branch] [-f|--force]
 	      [--reference <repository>] [--] <repository> [<path>]
+'git submodule' [--quiet] rm <path>...
 'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
 'git submodule' [--quiet] init [--] [<path>...]
 'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]

@@ -104,6 +105,17 @@ together in the same relative location, and only the
 superproject's URL needs to be provided: git-submodule will correctly
 locate the submodule using the relative URL in .gitmodules.
 
+rm::
+	Remove and unregister the submodules at given paths.
++
+This requires at least one <path> argument. The repository checkout
+existing at that directory needs to be removed manually from
+the filesystem prior to calling this command. Note that all local
+changes will be lost.
++
+This command removes the submodule from the current git index,
+the .gitmodules file and the local repository config.
+
 status::
 	Show the status of the submodules. This will print the SHA-1 of the
 	currently checked out commit for each submodule, along with the

diff --git a/git-submodule.sh b/git-submodule.sh
index fbf2faf..88fd414 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh

@@ -6,6 +6,7 @@
 
 dashless=$(basename "$0" | sed -e 's/-/ /')
 USAGE="[--quiet] add [-b branch] [-f|--force] [--reference <repository>] [--] <repository> [<path>]
+   or: $dashless [--quiet] rm [--] <path>...
    or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
    or: $dashless [--quiet] init [--] [<path>...]
    or: $dashless [--quiet] update [--init] [-N|--no-fetch] [-f|--force] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]

@@ -308,6 +309,71 @@ Use -f if you really want to add it." >&2
 }
 
 #
+# Remove submodules from the working tree, .gitmodules and the index
+#
+# $@ = submodule paths
+#
+cmd_rm()
+{
+	# parse $args after "submodule ... rm".
+	while test $# -ne 0
+	do
+		case "$1" in
+		--)
+			shift
+			break
+			;;
+		-*)
+			usage
+			;;
+		*)
+			break
+			;;
+		esac
+		shift
+	done
+
+	if test -z "$1"; then
+		usage
+	fi
+
+	while test $# -ne 0
+	do
+		sm_path=$1
+		shift
+
+		# normalize path:
+		# multiple //; leading ./; /./; /../; trailing /
+		sm_path=$(printf '%s/\n' "$sm_path" |
+			sed -e '
+				s|//*|/|g
+				s|^\(\./\)*||
+				s|/\./|/|g
+				:start
+				s|\([^/]*\)/\.\./||
+				tstart
+				s|/*$||
+			')
+		git ls-files --error-unmatch "$sm_path" > /dev/null 2>&1 ||
+		die "$(eval_gettext "'\$sm_path' does not exist in the index")"
+
+		if test -e "$sm_path"
+		then
+			die "$(eval_gettext "'\$sm_path' needs to be removed manually first")"
+		fi
+
+		git rm --cached "$sm_path" ||
+		die "$(eval_gettext "Failed to remove submodule '\$sm_path'")"
+
+		git config -f .gitmodules --remove-section submodule."$sm_path" &&
+		git add --force .gitmodules ||
+		die "$(eval_gettext "Failed to unregister submodule '\$sm_path'")"
+
+		git config --remove-section submodule."$sm_path"
+	done
+}
+
+#
 # Execute an arbitrary command sequence in each checked out
 # submodule
 #

@@ -996,7 +1062,7 @@ cmd_sync()
 while test $# != 0 && test -z "$command"
 do
 	case "$1" in
-	add | foreach | init | update | status | summary | sync)
+	add | rm | foreach | init | update | status | summary | sync)
 		command=$1
 		;;
 	-q|--quiet)

-- 
1.7.10.2

Am 25.06.2012 12:57, schrieb Michał Górny:

Add an 'rm' command to git-submodule which provides means to
(semi-)easily remove git submodules.

Signed-off-by: Michał Górny <redacted>
---
Right now, it requires the submodule checkout to be removed manually
first (so it does not remove unstaged commits), and just removes
the index entry and module information from config.

I based it on 'cmd_add' code trying to preserve the original coding
standards.

I really like the goal of this patch but would prefer that "git rm"
learns how to remove submodules instead of adding more code to the
git-submodule.sh script.

Also it shouldn't be necessary for the user to remove the directory
by hand before running "git rm". At least all files recorded in the
submodule can be removed (and if the submodule uses a gitfile that
can be removed too). Then all that is left are untracked files the
user has to decide what to do with (which might be removed too when
running "git rm --recurse-submodules=untracked").

Me thinks without -f a "git rm" should only then remove a submodule
if no local modifications exist and current HEAD is part of a remote
branch (so you can't loose unpushed commits by accident). If the
submodule uses a gitfile a local branch might be sufficient for that,
as the git directory lives on.

++
+This command removes the submodule from the current git index,
+the .gitmodules file and the local repository config.

It should not be removed from .git/config by default. The user may
have special settings there and the presence in .git/config shows
he cared about having the submodule checked out, which should not
be revoked by just removing the submodule from the work tree.
Unless he removes the config from there himself he should get back
a populated submodule when he checks out an earlier commit and says
"git submodule update".

On Mon, Jun 25, 2012 at 12:58 PM, Jens Lehmann [off-list ref] wrote:

Am 25.06.2012 12:57, schrieb Michał Górny:

quoted

Add an 'rm' command to git-submodule which provides means to
(semi-)easily remove git submodules.

Signed-off-by: Michał Górny <redacted>
---
Right now, it requires the submodule checkout to be removed manually
first (so it does not remove unstaged commits), and just removes
the index entry and module information from config.

I based it on 'cmd_add' code trying to preserve the original coding
standards.

I really like the goal of this patch but would prefer that "git rm"
learns how to remove submodules instead of adding more code to the
git-submodule.sh script.

I would like to see both supported, eventually. That is, git-rm and
git-submodule-rm should both work.  It would make sense to me when I
am looking for the counterpart to 'git submodule add' to find it under
'git submodule rm', and also under 'git submodule --help'.

Also it shouldn't be necessary for the user to remove the directory
by hand before running "git rm". At least all files recorded in the
submodule can be removed (and if the submodule uses a gitfile that
can be removed too). Then all that is left are untracked files the
user has to decide what to do with (which might be removed too when
running "git rm --recurse-submodules=untracked").

That sounds like a nice next step.  But I would expect that a 'git
[submodule] rm foo' where foo has uncommitted changes to complain to
me (and do nothing else) unless I used --force.  This is similar to
how git-rm already behaves, I think.  And in the case of a dirty
submodule it makes sense to treat the submodule files as an atomic
unit.  That is, if any of the submodule files are dirty and git-rm
will "leave" them, then it should leave the whole submodule.  It would
be very inconvenient to have to restore files back into place at the
correct commit just so I could examine them in context to determine
what I should have done with them before I used git-rm.

In the special case of a submodule which does not use a gitfile, I am
not even sure if any of the submodule files should be removed. If they
are, what state does that leave the submodule repository in?  A
checked-out workdir whose files are all removed?  'git-status' would
be very noisy in this case.  I'd rather expect this to behave the same
as if I checked out a previous commit which did not have the submodule
added yet.  Today, this leaves the submodule in-place and it shows up
as an untracked file.  I don't know a better way to handle that,
though I expect it would be ok remove all the files even in this case
(if the workdir is not dirty and if the head commit is current in the
superproject).  But it seems extreme to do all of that and then leave
the .git directory lying about in the former submodule directory.

Phil

Am 25.06.2012 22:53, schrieb Phil Hord:

On Mon, Jun 25, 2012 at 12:58 PM, Jens Lehmann [off-list ref] wrote:

quoted

Am 25.06.2012 12:57, schrieb Michał Górny:

quoted

Add an 'rm' command to git-submodule which provides means to
(semi-)easily remove git submodules.

Signed-off-by: Michał Górny <redacted>
---
Right now, it requires the submodule checkout to be removed manually
first (so it does not remove unstaged commits), and just removes
the index entry and module information from config.

I based it on 'cmd_add' code trying to preserve the original coding
standards.

I really like the goal of this patch but would prefer that "git rm"
learns how to remove submodules instead of adding more code to the
git-submodule.sh script.

I would like to see both supported, eventually. That is, git-rm and
git-submodule-rm should both work.  It would make sense to me when I
am looking for the counterpart to 'git submodule add' to find it under
'git submodule rm', and also under 'git submodule --help'.

Hmm, as long as "git submodule rm" would just use "git rm" under the
hood and not its own scripting that would be ok.

quoted

Also it shouldn't be necessary for the user to remove the directory
by hand before running "git rm". At least all files recorded in the
submodule can be removed (and if the submodule uses a gitfile that
can be removed too). Then all that is left are untracked files the
user has to decide what to do with (which might be removed too when
running "git rm --recurse-submodules=untracked").

That sounds like a nice next step.  But I would expect that a 'git
[submodule] rm foo' where foo has uncommitted changes to complain to
me (and do nothing else) unless I used --force.  This is similar to
how git-rm already behaves, I think.  And in the case of a dirty
submodule it makes sense to treat the submodule files as an atomic
unit.  That is, if any of the submodule files are dirty and git-rm
will "leave" them, then it should leave the whole submodule.  It would
be very inconvenient to have to restore files back into place at the
correct commit just so I could examine them in context to determine
what I should have done with them before I used git-rm.

We absolutely agree here, this is pretty much what I wrote further
down in my first response ;-)
(except additionally I consider a submodule dirty if it's HEAD isn't
on any branch to avoid loosing commits)

In the special case of a submodule which does not use a gitfile, I am
not even sure if any of the submodule files should be removed. If they
are, what state does that leave the submodule repository in?  A
checked-out workdir whose files are all removed?  'git-status' would
be very noisy in this case.  I'd rather expect this to behave the same
as if I checked out a previous commit which did not have the submodule
added yet.  Today, this leaves the submodule in-place and it shows up
as an untracked file.  I don't know a better way to handle that,
though I expect it would be ok remove all the files even in this case
(if the workdir is not dirty and if the head commit is current in the
superproject).  But it seems extreme to do all of that and then leave
the .git directory lying about in the former submodule directory.

Good point. Another option would be to move the git directory into
.git/modules of the superproject before removing the files, then next
time it's updated it'll use gitfile. But maybe that's a problem which
will go away anyways as all submodules cloned with newer git use
gitfiles anyway.

On Mon, Jun 25, 2012 at 5:09 PM, Jens Lehmann [off-list ref] wrote:

Am 25.06.2012 22:53, schrieb Phil Hord:

quoted

On Mon, Jun 25, 2012 at 12:58 PM, Jens Lehmann [off-list ref] wrote:

quoted

Am 25.06.2012 12:57, schrieb Michał Górny:

quoted

Add an 'rm' command to git-submodule which provides means to
(semi-)easily remove git submodules.

Signed-off-by: Michał Górny <redacted>
---
Right now, it requires the submodule checkout to be removed manually
first (so it does not remove unstaged commits), and just removes
the index entry and module information from config.

I based it on 'cmd_add' code trying to preserve the original coding
standards.

I really like the goal of this patch but would prefer that "git rm"
learns how to remove submodules instead of adding more code to the
git-submodule.sh script.

I would like to see both supported, eventually. That is, git-rm and
git-submodule-rm should both work.  It would make sense to me when I
am looking for the counterpart to 'git submodule add' to find it under
'git submodule rm', and also under 'git submodule --help'.

Hmm, as long as "git submodule rm" would just use "git rm" under the
hood and not its own scripting that would be ok.

Maybe it would be better if 'git-rm' would use 'git submodule rm'
under the covers.  This would keep the .gitmodules (etc.)
manipulations out of the hair of the git-rm machinery.

Also, I hope 'git submodule rm foo' would fail if 'foo' were not a submodule.

quoted

quoted

Also it shouldn't be necessary for the user to remove the directory
by hand before running "git rm". At least all files recorded in the
submodule can be removed (and if the submodule uses a gitfile that
can be removed too). Then all that is left are untracked files the
user has to decide what to do with (which might be removed too when
running "git rm --recurse-submodules=untracked").

That sounds like a nice next step.  But I would expect that a 'git
[submodule] rm foo' where foo has uncommitted changes to complain to
me (and do nothing else) unless I used --force.  This is similar to
how git-rm already behaves, I think.  And in the case of a dirty
submodule it makes sense to treat the submodule files as an atomic
unit.  That is, if any of the submodule files are dirty and git-rm
will "leave" them, then it should leave the whole submodule.  It would
be very inconvenient to have to restore files back into place at the
correct commit just so I could examine them in context to determine
what I should have done with them before I used git-rm.

We absolutely agree here, this is pretty much what I wrote further
down in my first response ;-)
(except additionally I consider a submodule dirty if it's HEAD isn't
on any branch to avoid loosing commits)

So you did.  What bothered me was the suggestion that you could
partially remove a submodule's files.

quoted

In the special case of a submodule which does not use a gitfile, I am
not even sure if any of the submodule files should be removed. If they
are, what state does that leave the submodule repository in?  A
checked-out workdir whose files are all removed?  'git-status' would
be very noisy in this case.  I'd rather expect this to behave the same
as if I checked out a previous commit which did not have the submodule
added yet.  Today, this leaves the submodule in-place and it shows up
as an untracked file.  I don't know a better way to handle that,
though I expect it would be ok remove all the files even in this case
(if the workdir is not dirty and if the head commit is current in the
superproject).  But it seems extreme to do all of that and then leave
the .git directory lying about in the former submodule directory.

Good point. Another option would be to move the git directory into
.git/modules of the superproject before removing the files, then next
time it's updated it'll use gitfile. But maybe that's a problem which
will go away anyways as all submodules cloned with newer git use
gitfiles anyway.

I like this idea, but it seems a little presumptuous.  The new
behavior might cause a few panicked users to spend the day rebuilding
their "lost" repository.  Maybe we can make this an explicit action.
"git submodule convert-to-gitfile"  :-)

Phil

Am 26.06.2012 21:12, schrieb Phil Hord:

On Mon, Jun 25, 2012 at 5:09 PM, Jens Lehmann [off-list ref] wrote:

quoted

Am 25.06.2012 22:53, schrieb Phil Hord:

quoted

On Mon, Jun 25, 2012 at 12:58 PM, Jens Lehmann [off-list ref] wrote:

quoted

Am 25.06.2012 12:57, schrieb Michał Górny:

quoted

Add an 'rm' command to git-submodule which provides means to
(semi-)easily remove git submodules.

Signed-off-by: Michał Górny <redacted>
---
Right now, it requires the submodule checkout to be removed manually
first (so it does not remove unstaged commits), and just removes
the index entry and module information from config.

I based it on 'cmd_add' code trying to preserve the original coding
standards.

I really like the goal of this patch but would prefer that "git rm"
learns how to remove submodules instead of adding more code to the
git-submodule.sh script.

I would like to see both supported, eventually. That is, git-rm and
git-submodule-rm should both work.  It would make sense to me when I
am looking for the counterpart to 'git submodule add' to find it under
'git submodule rm', and also under 'git submodule --help'.

Hmm, as long as "git submodule rm" would just use "git rm" under the
hood and not its own scripting that would be ok.

Maybe it would be better if 'git-rm' would use 'git submodule rm'
under the covers.  This would keep the .gitmodules (etc.)
manipulations out of the hair of the git-rm machinery.

I disagree, me thinks submodules should become first class citizens.

Also, I hope 'git submodule rm foo' would fail if 'foo' were not a submodule.

Yes, it should. But that'd be easy to test there.

quoted

quoted

In the special case of a submodule which does not use a gitfile, I am
not even sure if any of the submodule files should be removed. If they
are, what state does that leave the submodule repository in?  A
checked-out workdir whose files are all removed?  'git-status' would
be very noisy in this case.  I'd rather expect this to behave the same
as if I checked out a previous commit which did not have the submodule
added yet.  Today, this leaves the submodule in-place and it shows up
as an untracked file.  I don't know a better way to handle that,
though I expect it would be ok remove all the files even in this case
(if the workdir is not dirty and if the head commit is current in the
superproject).  But it seems extreme to do all of that and then leave
the .git directory lying about in the former submodule directory.

Good point. Another option would be to move the git directory into
.git/modules of the superproject before removing the files, then next
time it's updated it'll use gitfile. But maybe that's a problem which
will go away anyways as all submodules cloned with newer git use
gitfiles anyway.

I like this idea, but it seems a little presumptuous.  The new
behavior might cause a few panicked users to spend the day rebuilding
their "lost" repository.

Me thinks we should teach "git rm" only to remove the submodule when
the --recurse-submodules option is used with it (which is what "git
submodule rm" would do). Then later the to be added "autoupdate"
submodule config  setting (which I intend to use for automatic
submodule updates during checkout, merge, etc. too) could enable this.
No surprises for users who didn't ask for it.

 Maybe we can make this an explicit action.
"git submodule convert-to-gitfile"  :-)

I like it!

On Tue, Jun 26, 2012 at 3:59 PM, Jens Lehmann [off-list ref] wrote:

Am 26.06.2012 21:12, schrieb Phil Hord:

quoted

On Mon, Jun 25, 2012 at 5:09 PM, Jens Lehmann [off-list ref] wrote:

quoted

Am 25.06.2012 22:53, schrieb Phil Hord:

quoted

On Mon, Jun 25, 2012 at 12:58 PM, Jens Lehmann [off-list ref] wrote:

quoted

Am 25.06.2012 12:57, schrieb Michał Górny:

quoted

Add an 'rm' command to git-submodule which provides means to
(semi-)easily remove git submodules.

Signed-off-by: Michał Górny <redacted>
---
Right now, it requires the submodule checkout to be removed manually
first (so it does not remove unstaged commits), and just removes
the index entry and module information from config.

I based it on 'cmd_add' code trying to preserve the original coding
standards.

I really like the goal of this patch but would prefer that "git rm"
learns how to remove submodules instead of adding more code to the
git-submodule.sh script.

I would like to see both supported, eventually. That is, git-rm and
git-submodule-rm should both work.  It would make sense to me when I
am looking for the counterpart to 'git submodule add' to find it under
'git submodule rm', and also under 'git submodule --help'.

Hmm, as long as "git submodule rm" would just use "git rm" under the
hood and not its own scripting that would be ok.

Maybe it would be better if 'git-rm' would use 'git submodule rm'
under the covers.  This would keep the .gitmodules (etc.)
manipulations out of the hair of the git-rm machinery.

I disagree, me thinks submodules should become first class citizens.

Sounds ok to me.  But maybe keep it in a separate module just for
manipulating submodules; you know, to reduce our spaghetti score.

quoted

Also, I hope 'git submodule rm foo' would fail if 'foo' were not a submodule.

Yes, it should. But that'd be easy to test there.

quoted

quoted

quoted

In the special case of a submodule which does not use a gitfile, I am
not even sure if any of the submodule files should be removed. If they
are, what state does that leave the submodule repository in?  A
checked-out workdir whose files are all removed?  'git-status' would
be very noisy in this case.  I'd rather expect this to behave the same
as if I checked out a previous commit which did not have the submodule
added yet.  Today, this leaves the submodule in-place and it shows up
as an untracked file.  I don't know a better way to handle that,
though I expect it would be ok remove all the files even in this case
(if the workdir is not dirty and if the head commit is current in the
superproject).  But it seems extreme to do all of that and then leave
the .git directory lying about in the former submodule directory.

Good point. Another option would be to move the git directory into
.git/modules of the superproject before removing the files, then next
time it's updated it'll use gitfile. But maybe that's a problem which
will go away anyways as all submodules cloned with newer git use
gitfiles anyway.

I like this idea, but it seems a little presumptuous.  The new
behavior might cause a few panicked users to spend the day rebuilding
their "lost" repository.

Me thinks we should teach "git rm" only to remove the submodule when
the --recurse-submodules option is used with it (which is what "git
submodule rm" would do). Then later the to be added "autoupdate"
submodule config  setting (which I intend to use for automatic
submodule updates during checkout, merge, etc. too) could enable this.
No surprises for users who didn't ask for it.

I like that, though I despise the --recurse-submodules option because
A) it is too long, and B) it is sometimes spelled "--recurse" (for
good reasons, I'm sure, but it's irritating nonetheless).

quoted

 Maybe we can make this an explicit action.
"git submodule convert-to-gitfile"  :-)

I like it!

On Mon, 25 Jun 2012 18:58:36 +0200
Jens Lehmann [off-list ref] wrote:

Am 25.06.2012 12:57, schrieb Michał Górny:

quoted

Add an 'rm' command to git-submodule which provides means to
(semi-)easily remove git submodules.

Signed-off-by: Michał Górny <redacted>
---
Right now, it requires the submodule checkout to be removed manually
first (so it does not remove unstaged commits), and just removes
the index entry and module information from config.

I based it on 'cmd_add' code trying to preserve the original coding
standards.

I really like the goal of this patch but would prefer that "git rm"
learns how to remove submodules instead of adding more code to the
git-submodule.sh script.

My main intent was, like Phil already pointed out, to provide
a counterpart to 'git submodule add'. I don't mind 'git rm' supporting
removing submodules but that's not exactly what I would consider...
friendly?

What I'm trying to express is that if I added a submodule using 'git
submodule add', I would expect to have 'git submodule rm'. Honestly, I
didn't even think about trying using 'git rm' on a submodule.
The correct results of such a call are hard to predict to me.

Also it shouldn't be necessary for the user to remove the directory
by hand before running "git rm". At least all files recorded in the
submodule can be removed (and if the submodule uses a gitfile that
can be removed too). Then all that is left are untracked files the
user has to decide what to do with (which might be removed too when
running "git rm --recurse-submodules=untracked").

Except for the untracked files there may also be commits which were not
pushed anywhere. Honestly, I didn't want to get into that risky area in
the first patch.

As the next step, I'd see adding a '--force' option to actually enforce
removing the directory. But I'd like the basics to start working first,
then consider harder things.

quoted

++
+This command removes the submodule from the current git index,
+the .gitmodules file and the local repository config.

It should not be removed from .git/config by default. The user may
have special settings there and the presence in .git/config shows
he cared about having the submodule checked out, which should not
be revoked by just removing the submodule from the work tree.
Unless he removes the config from there himself he should get back
a populated submodule when he checks out an earlier commit and says
"git submodule update".

Ok, I will change that.

-- 
Best regards,
Michał Górny