On Thu, Sep 15, 2016 at 9:40 AM, Yaroslav Halchenko <y...@onerussian.com> wrote: > > On Thu, 15 Sep 2016, Stefan Beller wrote: > >> > I think it would be more logical to make it a 'warning:' not a 'fatal:' and >> > proceed. > >> So maybe we would want to introduce a switch >> `--existing-but-unconfigure-gitlinks=(warn|ignore)` >> as well as >> `git config submodule.existing-but-unconfigured (warn|ignore)` >> for a more permanent solution? > > possibly ignorant question: is gitlink === Subproject or a > Subproject is a kinda of a gitlink and there are other gitlinks which > aren't Subprojects? ;) >
gitlink is the internal name (just like a file is called blob, or a directory is called tree; there is no file system equivalent for e.g. commits, or gitlinks) gitlinks as a basic building block only points at a sha1 to be part of the repository. Submodules use gitlinks to point at (usually) different projects, e.g. a library. Subprojects in Git is a loose term, it could mean submodule or part of your repo merged in via the git-subtree command. Or a sub project can be just a loose repository inside your repository. gitlinks do not necessarily need to track other projects; it's "just a pointer" to a specific version of a repository. So to come back to your question: yeah In that response I meant submodule==gitlink, though naming the internal data structure to be more explicit. (What if we invent a new way to do submodules not using gitlinks? Then that config option may be less confusing and backwards compatible. That is unlikely though. So I guess we'll settle with a different name)
