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

[Heiko Voigt <hvoigt@hvoigt.net>]

On Thu, Sep 15, 2016 at 11:27:54AM -0700, Junio C Hamano wrote:
> Stefan Beller <sbeller@google.com> writes:
> > 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.

How about just

   git submodule add <submodulepath>

? I remember back in the days when I started with submodules thats the
way I imagined submodules would work:

1. clone the submodule into a directory
2. git submodule add it
3. git commit everything

Because that how you basically work with files.  So instead of adding
another option I would rather like to autodetect that:

 * its a relative path inside this repo that is passed to
   'git submodule add'
 * there is no .gitmodules entry
 * and no .git/config
==> create those from a remote in the submodule

Corner cases:

 * If there is more than one remote we could tell the user to use an
   option to specify which one to use.
 * Barf in case there is no remote (not adding the submodule except -f
   is used).
 * If the gitlink is already there but no .gitmodules entry, 'git
   submodule add' will just add the entry as if it was initially added.

Instead of giving an error message that the submodule is already added
we could actually be nicer to the user and try to fix things for him
instead.

Cheers Heiko