* nested git repos (not submodules)
@ 2012-02-10 2:34 Neal Kreitzinger
2012-02-10 3:47 ` Andrew Ardill
2012-02-10 4:16 ` Junio C Hamano
0 siblings, 2 replies; 5+ messages in thread
From: Neal Kreitzinger @ 2012-02-10 2:34 UTC (permalink / raw)
To: git
In the worktree of a particular git repo, the user has made a subdir
(worktree/subdir) of the worktree (worktree/.git) its own repo
(worktree/subdir/.git). Is there a danger of worktree/.git and
worktree/subdir/.git crossing wires? Are literally nested git repos (whose
worktrees are in turn tracked as subdirs by upper-level git repo(s)) a
supported/valid model in regards to git.git (NOT git-addons)?
Symptomatically, I have observed the following so far:
(1) worktree/.git is "ignoring" (or unaware of) worktree/subdir/.git because
it is treating subdir/ as if subdir/.git wasn't there and is not listing
subdir/.git as untracked. I'm not sure if this is an unintended side-effect
of git ignoring .git(s) automatically, or if having subdir/.git's (w/out
having them defined as submodules) is an expected
(reasonable/sane/recommended) model for git.git users.
(2) running git commands with pwd=worktree/subdir/ acts upon
worktree/subdir/.git (subdir/ is regarded as the toplevel of subdir/.git as
opposed to a subdir of worktree/.git) and is seemingly oblivious to
worktree.git.
I suspect submodules is the "correct" way to implement the effect of nested
git repos. That being said, this literal nested git repo is a temporary
band-aid and I don't expect it to be propogated, but I do have to deal
(react) with it in the meantime. I'm thinking I can manage that and deal
with annoyances as they arise, unless there are any unseen landmines I'm not
aware of. Please advise.
(I also wouldn't be surprised to hear that this is exactly how submodules
really first started in theory or practice.)
Thanks in advance for any feedback.
v/r,
neal
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nested git repos (not submodules)
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
1 sibling, 1 reply; 5+ messages in thread
From: Andrew Ardill @ 2012-02-10 3:47 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
> Thanks in advance for any feedback.
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.
Out of interest, what itch are you scratching by using this model?
Regards,
Andrew Ardill
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nested git repos (not submodules)
2012-02-10 2:34 nested git repos (not submodules) Neal Kreitzinger
2012-02-10 3:47 ` Andrew Ardill
@ 2012-02-10 4:16 ` Junio C Hamano
2012-02-10 22:30 ` Neal Kreitzinger
1 sibling, 1 reply; 5+ messages in thread
From: Junio C Hamano @ 2012-02-10 4:16 UTC (permalink / raw)
To: Neal Kreitzinger; +Cc: git
"Neal Kreitzinger" <neal@rsss.com> writes:
> In the worktree of a particular git repo, the user has made a subdir
> (worktree/subdir) of the worktree (worktree/.git) its own repo
> (worktree/subdir/.git). Is there a danger of worktree/.git and
> worktree/subdir/.git crossing wires?
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 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.
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nested git repos (not submodules)
2012-02-10 3:47 ` Andrew Ardill
@ 2012-02-10 22:07 ` Neal Kreitzinger
0 siblings, 0 replies; 5+ messages in thread
From: Neal Kreitzinger @ 2012-02-10 22:07 UTC (permalink / raw)
To: Andrew Ardill; +Cc: Neal Kreitzinger, git
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: nested git repos (not submodules)
2012-02-10 4:16 ` Junio C Hamano
@ 2012-02-10 22:30 ` Neal Kreitzinger
0 siblings, 0 replies; 5+ messages in thread
From: Neal Kreitzinger @ 2012-02-10 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Neal Kreitzinger, git
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-02-10 22:31 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
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 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.