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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Sep 16, 2016 at 7:11 AM, Heiko Voigt <hvoigt@xxxxxxxxxx> wrote:
> 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.
>

This makes sense to me. Possibly we could warn in this case, so that
the user knows that something was "off" but I don't think we should be
failing here...

Regards,
Jake

> Cheers Heiko



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]