nested git repos (not submodules)

nested git repos (not submodules)

[Neal Kreitzinger]

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 

Re: nested git repos (not submodules)

[Andrew Ardill]

> 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

Re: nested git repos (not submodules)

[Neal Kreitzinger]

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

Re: nested git repos (not submodules)

[Junio C Hamano]

"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.

Re: nested git repos (not submodules)

[Neal Kreitzinger]

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