Add support for submodules

[r-hoogenboom]

trafficstars

Git has crude provisions for submodules. Maybe gitless can sanitize the use of submodules too. Take good care (better than git) of the branch of the submodule. Also don't use different names for submodule operations as for the main repo operations, like git does.

[embs]

Hi @spderosso @r-hoogenboom

I'd like to tackle this one. Did you already start thinking about how it should work? If not, I can come up with a proposal.

[r-hoogenboom]

Something like: gl submodule init [ [<tag/branch/hash>]] (clone or start a submodule) gl submodule switch <tag/branch/hash> gl submodule list (list all submodules in repo with their tag/branch/hash) gl submodule merge/fuse (do fuse or merge of all submodules -- update)

When there are submodules, the option -r[ecursive] for gl publish will publish the submodule repositories too (or maybe that should be the default). When a repo is inited from a remote repo that has submodules, these submodules are checked out as well (but should be preventable by some option).

For all other operations, cd to the submodule directory(ies) and use the normal gl commands.

Questions: if in the submodule dir the branch is switched, should the main repo remember this as a change, like I intended with the gl submodule switch? What about cross-site submodules? should there be some control/preference maybe?

[embs]

Thank you for your suggestions, @r-hoogenboom.

LGTM. I'd only add that we should strive easing the pain of removing git submodules -- which appears as the top most relevant questions in StackOverflow when we search for git submodules. This could be only

gl submodule rm path/to/submodule

maybe?

When there are submodules, the option -r[ecursive] for gl publish will publish the submodule repositories too

This doesn't sound intuitive to me but I may be biased by the use of git. I guess we could wait for more feedback and leave it for a second phase implementation of the gl submodule feature.

if in the submodule dir the branch is switched, should the main repo remember this as a change, like I intended with the gl submodule switch?

What would be the consequences of "remembering" the change in the main repo? Would it be that when gl status in main repo happens, it'd also include status about the submodule?

What about cross-site submodules?

What do you mean by cross-site submodules?

[r-hoogenboom]

gl submodule rm might lead someone to believe that the whole tree will be deleted, while you probably mean to just 'unlink' it as a submodule. Maybe gl submodule uninit is better?

Maybe the recursive behavior for publish and init should be default and some option to prevent recursive behavior if the user wants more control.

The cross-site submodules is when the remote repo of the submodule is on another server than the main one. This might pose some security concerns, like cross-site scripting.