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 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)

Reply via email to