From: Neal Kreitzinger <nkreitzinger@gmail.com>
To: Andrew Ardill <andrew.ardill@gmail.com>
Cc: Neal Kreitzinger <neal@rsss.com>, git@vger.kernel.org
Subject: Re: nested git repos (not submodules)
Date: Fri, 10 Feb 2012 16:07:36 -0600 [thread overview]
Message-ID: <4F359528.1060603@gmail.com> (raw)
In-Reply-To: <CAH5451mU5G-_FaPkpuhKrHAt4_5wiECj=-j9wkA_Ctb=27ncQg@mail.gmail.com>
On 2/9/2012 9:47 PM, Andrew Ardill wrote:
> My understanding was that such a configuration is essentially
> tracking the same set of files in two different git repositories. The
> location of the .git is not important, I could just as easily set the
> working directory of any git repository to be a folder tracked by
> another repository.
>
> My concerns would be based primarily on the different repositories
> trying to act on the same files at the same time. Ignoring the
> sub-folder completely within the encompassing repository would avoid
> that, however you might have use cases that prohibit that.
>
WORKTREE/SUBDIR/ was already tracked by WORKTREE/.git because the files
in WORKTREE/SUBDIR/ directly correlate to WORKTREE/ files (ie.,
WORKTREE/., WORKTREE/SUBDIR2/., WORKTREE/SUBDIR3/.). This is the
published model.
> Out of interest, what itch are you scratching by using this model?
>
(I can only speculate) I think it was intended to ensure that he would
only be modifying the WORKTREE/SUBDIR/ files of WORKTREE/.git. He did
some sequence of commands with the end result of:
(a) bare repo HISPATH/SUBDIR.git
and
(b1)
WORKTREE/.git
WORKTREE/SUBDIR/
is now
(b2)
WORKTREE/.git
WORKTREE/SUBDIR/.git
which means that the files of WORKTREE/SUBDIR are now tracked by
WORKTREE/.git and WORKTREE/SUBDIR/.git, as you stated.
Due to a drop-dead short-term deadline, I am being compelled to "just
deal with it" (work around the annoyances) unless there is a dire reason
it will blow up in our faces. At this point, (b2) is more-or-less an
intermediate "integration repo" between (a) and (b1-canonical), and I'm
assuming I can just jump thru some hoops to accomplish the integration
when the time comes (unless I hear of or step on any landmines).
Now that the newsgroup has confirmed that having "a repo that tracks 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'm not open to new
ideas.
v/r,
neal
next prev parent reply other threads:[~2012-02-10 22:07 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 [this message]
2012-02-10 4:16 ` Junio C Hamano
2012-02-10 22:30 ` Neal Kreitzinger
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=4F359528.1060603@gmail.com \
--to=nkreitzinger@gmail.com \
--cc=andrew.ardill@gmail.com \
--cc=git@vger.kernel.org \
--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).