git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jens Lehmann <Jens.Lehmann@web.de>
To: Manuel Koller <koller.manuel@gmail.com>
Cc: Fredrik Gustafsson <iveqy@iveqy.com>,
	Thomas Rast <trast@student.ethz.ch>,
	git@vger.kernel.org, Heiko Voigt <hvoigt@hvoigt.net>
Subject: Re: Git Submodule Problem - Bug?
Date: Tue, 29 Nov 2011 18:42:03 +0100	[thread overview]
Message-ID: <4ED5196B.5030200@web.de> (raw)
In-Reply-To: <20111129104105.GA10839@kolya>

Am 29.11.2011 11:41, schrieb Fredrik Gustafsson:
> On Tue, Nov 29, 2011 at 11:25:41AM +0100, Thomas Rast wrote:
>> So maybe the right questions to ask would be: what's the *official*
>> way of removing a submodule completely?  Do we support overwriting
>> submodules in the way Manuel wanted to?  Why not? :-)
> 
> I suggest that we add a command for that;
> git submodule remove <submodule>

Hmm, to me it looks like the problem is in "git submodule add". It
doesn't check if the submodule repo it finds in .git/modules matches
the one the user wants to create. So we end up reviving the first
submodule although the user wants to use a completely different repo.

One solution could be to only let "git submodule update" revive
submodules from .git/modules and make "git submodule add" error out
if it finds the git directory of a submodule with the same name in
.git/modules. But currently there is no way to tell "git submodule add"
to use a different submodule name (it always uses the path as a name),
so we might have to add an option to do that and tell the user in the
error message how he can add a different submodule under the same
path.

Another solution could be that "git submodule add" detects that a
submodule with the name "sub" did exist and chooses a different name
(say "sub2") for the the new one. Then the user wouldn't have to
cope with the problem himself.

  reply	other threads:[~2011-11-29 17:42 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-28 17:13 Git Submodule Problem - Bug? Manuel Koller
2011-11-29  9:24 ` Thomas Rast
2011-11-29 10:15   ` Fredrik Gustafsson
2011-11-29 10:25     ` Thomas Rast
2011-11-29 10:41       ` Fredrik Gustafsson
2011-11-29 17:42         ` Jens Lehmann [this message]
2011-11-29 18:15           ` Manuel Koller
2011-11-29 19:21             ` Junio C Hamano
2011-11-29 22:03           ` Heiko Voigt
2011-12-07  8:21             ` Manuel Koller
2011-12-07 21:56               ` Jens Lehmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4ED5196B.5030200@web.de \
    --to=jens.lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=hvoigt@hvoigt.net \
    --cc=iveqy@iveqy.com \
    --cc=koller.manuel@gmail.com \
    --cc=trast@student.ethz.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).