All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Lehmann <Jens.Lehmann@web.de>
To: John Szakmeister <john@szakmeister.net>
Cc: Git mailing list <git@vger.kernel.org>
Subject: Re: Nesting a submodule inside of another...
Date: Tue, 12 Jul 2011 21:23:13 +0200	[thread overview]
Message-ID: <4E1C9F21.6070300@web.de> (raw)
In-Reply-To: <CAEBDL5XQDehUyqKoazxy+YVHh_2iAyt9aE-77H1jZg4oujMJgw@mail.gmail.com>

Am 12.07.2011 14:01, schrieb John Szakmeister:
> I've got a project where we have several frameworks involved, and
> external modules we want to pull into the framework tree.  We'd like
> to make use of submodules and have something like this:
>     top-level/            <-- .gitmodules lives here
>         src/
>         framework1/   <-- a submodule
>             module/     <-- another submodule
>         framework2/   <-- a submodule
>             module2/    <-- another submodule
> 
> Currently, git fails trying to do this.  It's not happy about
> .gitmodules living at the top-level and nesting a submodule inside of
> another[1].  Is there a technical reason that this is not allowed?

Submodules are repositories of their own, so their work tree is outside
the superproject's work tree. You're attempting to have a submodule of
the superproject inside another submodule of the superproject, but this
won't work because it does not live in the superproject's work tree (as
that doesn't include submodules and their subdirectories).

To have nested submodules you must add "module" as a submodule of
"framework1" and "module2" as a submodule of "framework2". Then git
will handle them just fine (assuming you use the --recursive option for
"git submodule update" and friends). Of course that means that if you
want to record a new commit of a sub-submodule in the superpoject, you'll
have to commit that in it's parent submodule first and then can record
that commit in the superproject. (But if "framework1" wouldn't depend on
a specific version of "module", there would be no reason to put it inside
it in the first place, right?)

> Limiting the traversal up the tree, etc.?  I've worked around the lack
> of support to do this for now, but it would be really nice if we could
> do such a thing.

I can't think of a sane way to make that work.

> [1]  I may generate a patch for the error message, as the current
> implementation obscures the real error message.  When I try this, git
> says:
>     The following path is ignored by one of your .gitignore files:
>     framework1/module
>     Use -f if you really want to add it.
> 
>     After some careful debugging, I found out the real error message
> was about this sort of nesting being disallowed.

But at least since 1.6.2 git should issue a meaningful error message.
With current master I get:

$ git add sub/file
fatal: Path 'sub/file' is in submodule 'sub'

What version are you using?

  reply	other threads:[~2011-07-12 19:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-12 12:01 Nesting a submodule inside of another John Szakmeister
2011-07-12 19:23 ` Jens Lehmann [this message]
2011-07-13  1:21   ` John Szakmeister
2011-07-13 21:20     ` Jens Lehmann
2011-07-13 21:27       ` Junio C Hamano
2011-07-13 22:04         ` Jens Lehmann
2011-07-13 22:44           ` Junio C Hamano
2011-07-14  9:36       ` John Szakmeister
2011-07-14 14:33         ` Seth Robertson
2011-07-15  8:34           ` John Szakmeister
2011-07-13  8:43 ` Andreas Ericsson

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=4E1C9F21.6070300@web.de \
    --to=jens.lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=john@szakmeister.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.