Hello Aharon,
‘gx’ command only works with so-called “bare” Git repositories, not working copies. Bare Git repositories are usually used on the server side, while non-bare repositories are usually created by “git clone” command.
Git X-Modules is a server-side tool, so it is designed to work on the server side with bare Git repositories rather than on the client side with cloned working copies.
I would recommend you to run
$ gx demo /path/for/demo --repos-only
command and follow its instructions to get the idea how the command line tool works.
How soon until you have a plug-in for GitHub? Our flow is based on GitHub, not local repos. I am very interested in gx as it looks to meet our needs pretty closely.
Sorry for the delayed answer - we’re currently waiting for a reply from GitHub to clarify a few things, that will affect our pricing system. Are you interested in the pricing for individual users or organizations?
We are a commercial organization. Currently under 30 people are using Git.
I also have a question about how branching works. If I create a branch in a parent repo with submodules, I don’t see the branches making their way back to the original submodule repos. We’d really like this sort of thing to work, so that we can work independently on the submodules and on the projects that include them and have everything visible either way.
The feature you mentioned is supported by the core Git X-Modules engine but is not yet available in the UI.
For now, after creating a new branch in a repository, you also need to manually create a new module (or to edit an existing one), specifying which branch in a parent repository is to be synchronized with which branch in a module repository.
We are definitely planning to release this feature in one of the first major updates to the product. After that, when a new branch refs/heads/foo is created in the parent repository, Git X-Modules will automatically create a synchronized branch refs/heads/namespace/foo in the module repository.