nested subrepos

[ecraven]

I'm working on a php project, I have a core, and inside the core, in various nested directories, plugins. I'd like to have one git branch for the core, and one for each plugin.
If I try to clone them with git subrepo into nested subdirectories, strange things happen:

git subrepo clone /path/to/core core
git subrepo clone /path/to/plugin core/plugin
git subrepo status

This now shows one subrepo, core (although the actual data is checked out and present).
How do I properly nest subrepos? I don't want to include plugin in the core repo, but I want one "working" repo that has all the plugins inside core in various places.

Thanks for any help,

Peter

[ingydotnet]

Hi @ecraven. Thanks for the report.

Subrepos were made so that you could git subrepo clone repos, that themselves
had subrepos. It was not intended that you could clone subrepos under a subdir
that was already a subrepo. I should patch to not allow that.

If you run this command on the ingydotnet/git-subrepo itself:

find . -name .gitrepo

you'll see that there are nested subrepos! There are 4 .gitrepo files in all.
But then run:

git subrepo status

And you'll only see 2. That's because git-subrepo repo only cloned in 2
subrepos, but one of them had 2 subrepos itself.

This is the intended behavior.

It sounds like you are working on WordPress? WordPress is an area I would like
to see make use of subrepos, and probably for the reasons you want. So I'd like
to help you get happy.

One simple solution might be this:

git subrepo clone /path/to/plugin plugins/plugin
ln -s core/plugin ../plugins/plugin

In other words, put the plugin subrepos in their own plugins subdir and then
figure out a way so that the core can find them. Maybe using symlinks, maybe
something else.

Let me know what you think.

[ingydotnet]

I've been thinking on this and my mental model has shifted…

I used to think that sub-subrepos should be invisible to the parent repo, but
now I think we should expose them as far as the credentials of the author allow
them to go.

In other words, if I am the owner or collaborator on a subrepo of some subrepo,
I should be push directly to its upstream.

I should also see the sub-subrepos (and sub-sub-subrepos etc) in a status
command. Although I suspect I'll want to make that aspect clear, perhaps by
indentation.

I'll start the subsubrepo branch for this work.

[grimmySwe]

@ingydotnet
I tested the current git-subrepo (0.2.3 with issue/98) and currently it seems that when you do git subrepo status you only show the top level subrepos. But if I do specific operations on a sub-sub repo it works.

I think that this is exactly what I want. It will allow me to work on any subrepo as long as a specify it uniquely. But if I do operations without specifying any I only see the top nodes, this is good if you consider that it might be conflicts if you do git subrepo pull --all, what state should have precedence in case of a sub-subrepo?

[ingydotnet]

@grimmySwe those are good points. We might want to think about a --ALL option, or some better pattern matching options.

Not sure yet.

[ingydotnet]

@grimmySwe,

Thinking about this again. Since status with no arguments shows top level
stuff, can we make --all show everything.

Given the proper doc this makes sense to me. Otherwise how, using subrepo
commands only, does one become aware of all the subrepos?

[grimmySwe]

@ingydotnet I agree with you. It seems like a good way to use the --all flag so that you could list all possible subrepos in the tree structure.

[ingydotnet]

Added #132

I want to leave this open because I want to make sure everything is hunky dory
with subsubrepos.

[sixtyfive]

Hi. Do the referenced, closed, issues mean that this is officially sanctioned by now?