From: Neal Kreitzinger <nkreitzinger@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Neal Kreitzinger <neal@rsss.com>, git@vger.kernel.org
Subject: Re: nested git repos (not submodules)
Date: Fri, 10 Feb 2012 16:30:57 -0600 [thread overview]
Message-ID: <4F359AA1.2000901@gmail.com> (raw)
In-Reply-To: <7vd39ns4py.fsf@alter.siamese.dyndns.org>
On 2/9/2012 10:16 PM, Junio C Hamano wrote:
>
> The repository controlled by worktree/.git should behave as if subdir/
> does not exist, except that obviously the project cannot have a regular
> file "subdir" in it. When you chdir to worktree/subdir, everything in
> there should behave as if worktree/.git directory does not exist.
>
> At least that is the design, and it indeed is how I arrange my primary
> working tree (I have two "clones" at /git/git.git/ and /git/git.git/Meta,
> and the latter has a checkout of the "todo" branch), so I would make
> noises about any breakage for such a layout.
>
I now see that most of the concept of "a repo worktree path with an o/s
subdir containing another repo" is valid provided that the repo is
ignoring the worktree of the subdir repo.
> I do not know offhand if an attempt to add files inside subdir to the
> repository controlled by worktree/.git is always correctly prohibited by
> the code, though, as our code often forgets to error out "stupid user
> mistakes", and running "git add subdir/bar" when in worktree/ falls into
> that category.
>
In my situation, WORKTREE/.git is tracking the worktree of
WORKTREE/SUBDIR/.git. Before WORKTREE/SUBDIR/.git was created,
WORKTREE/SUBDIR/ was already being tracked by WORKTREE/.git because
WORKTREE/SUBDIR/. directly correlates to the rest of WORKTREE/.,
WORKTREE/SUBDIR2/., etc. Now that I know that having "a repo tracking
the worktree of a nested repo" is not a sound model, I can advise
against it on a go-forward basis without being concerned that I am not
open to new ideas.
> And the use of that layout predates the submodules by a large margin.
> In fact, when people suggest use of submodules when the toplevel and the
> sublevel do not even need tight version dependencies, some of their use
> cases might be better supported by using the simply-nested layout without
> even letting the toplevel be aware of the sublevel.
I will keep this in mind when adding submodules.
Thanks!
v/r,
neal
prev parent reply other threads:[~2012-02-10 22:31 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-10 2:34 nested git repos (not submodules) Neal Kreitzinger
2012-02-10 3:47 ` Andrew Ardill
2012-02-10 22:07 ` Neal Kreitzinger
2012-02-10 4:16 ` Junio C Hamano
2012-02-10 22:30 ` Neal Kreitzinger [this message]
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=4F359AA1.2000901@gmail.com \
--to=nkreitzinger@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=neal@rsss.com \
/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).