git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 2/2] git-submodule: support 'rm' command.

From
Michał Górny <mgorny@gentoo.org>
Date
Jun 28, 2012, 20:31 UTC
Message-ID
<20120628223106.5bc9735e@pomiocik.lan>
In-Reply-To
<4FE898BC.2020307@web.de>

On Mon, 25 Jun 2012 18:58:36 +0200 Jens Lehmann <Jens.Lehmann@web.de> wrote:

Show 16 quoted lines
> 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 <mgorny@gentoo.org>
> > ---
> > 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.

Show 6 quoted lines
> 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.

Show 11 quoted lines
> > ++
> > +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
Previous: Phil Hord
Message 9 of 9 in “git-submodule.sh: fix filename in comment.”
  1. 1/2 git-submodule.sh: fix filename in comment.Michał Górny, Jun 25, 2012
  2. 2/2 git-submodule: support 'rm' command.Michał Górny, Jun 25, 2012
  3. Jens LehmannJun 25, 2012
  4. Phil HordJun 25, 2012
  5. Jens LehmannJun 25, 2012
  6. Phil HordJun 26, 2012
  7. Jens LehmannJun 26, 2012
  8. Phil HordJun 27, 2012
  9. Michał GórnyJun 28, 2012

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.