Stefan Beller <sbeller@xxxxxxxxxx> writes: > This is similar to the gitignore document, but doesn't mirror > the current situation. It is rather meant to start a discussion for > the right approach for mirroring repositories with submodules. > > Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx> > --- > > Jonathan, is this something you had in mind? > > Documentation/git-submodule.txt | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt > index 13adebf..b5559e5 100644 > --- a/Documentation/git-submodule.txt > +++ b/Documentation/git-submodule.txt > @@ -59,6 +59,22 @@ instead of treating the other project as a submodule. Directories > that come from both projects can be cloned and checked out as a whole > if you choose to go that route. > > +Submodule operations can be configured using the following mechanisms > +(from highest to lowest precedence): > + > + * the command line for those commands that support taking submodule specs. Sorry, but have we introduced <submodule spec> as a Git lingo? What does it mean? > + > + * the configuration file `$GIT_DIR/config`. > + > + * the configuration file `config` found in the `refs/submodule/config` branch. > + This can be used to overwrite the upstream configuration in the `.gitmodules` > + file without changing the history of the project. > + Useful options here are overwriting the base, where relative URLs apply to, > + when mirroring only parts of the larger collection of submodules. This smells like something server side people may come up with; how would an end user with a usual "repository with working tree" layout futz with this thing? Can it even be checked out, or would we have a UI similar to "notes"? > + * the `.gitmodules` file inside the repository. A project usually includes this > + file to suggest defaults for the upstream collection of repositories. > + > COMMANDS > -------- > add:: -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html