Re: [wishlist?] make submodule commands robust to having non-submodule Subprojects

[Junio C Hamano <gitster@pobox.com>]

Stefan Beller <sbeller@google.com> writes:

>     When searching around the net, some people use half
>     initialized submodules intentionally,...
>
> Not sure I agree with such a setup, but people use it.

In such a top-level project, people would not use "git submodule"
command, would they?  I do not think anybody in this thread was
pushing to forbid such a use, and it may be perfectly fine if "git
submodule" does not work for such a gitlink; after all such a
subdirectory is not even meant to be a submodule.

> So how about this fictional work flow:
>
>          $ git init top
>          $ cd top
>          $ git commit --allow-empty -m 'initial in top'
>          $ git init sub
>          $ git -C sub commit --allow-empty -m 'initial in sub'
>          $ git add sub
>         You added a gitlink, but no corresponding entry in
>         .gitmodules is found. This is fine for gits core functionality, but
>         the submodule command gets confused by this unless you add 'sub'
>         to your .gitmodules via `git submodule add --already-in-tree \
>         --reuse-submodules-origin-as-URL sub`. Alternatively you can make this
>         message disappear by configuring advice.gitlinkPitfalls.

I am not sure if I agree with that direction.

If the trend in Git community collectively these days is to make
usage of submodules easier and smoother, I'd imagine that you would
want to teach "git add" that was given a submodule to "git submodule
add" instead by default, with an option "git add --no-gitmodules
sub" to disable it, or something like that.

>          $ git submodule add --fixup-modules-file ./sub sub
>          Adding .gitmodule entry only for `sub` to use `git -C remote
> show origin` as URL.

I agree that a feature like this is needed regardless of what
happens at "git add" time.