On Thu, Jun 22, 2017 at 2:03 PM, Brandon Williams <bmwill@xxxxxxxxxx> wrote: > On 06/22, Stefan Beller wrote: >> On Thu, Jun 22, 2017 at 1:20 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> > Brandon Williams <bmwill@xxxxxxxxxx> writes: >> > >> >> On 06/20, Stefan Beller wrote: >> >> ... >> >>> +The configuration of submodules >> >>> +------------------------------- >> >>> + >> >>> +Submodule operations can be configured using the following mechanisms >> >>> +(from highest to lowest precedence): >> >>> + >> >>> + * the command line for those commands that support taking submodule specs. >> >>> + >> >>> + * the configuration file `$GIT_DIR/config` in the superproject. >> >>> + >> >>> + * the `.gitmodules` file inside the superproject. A project usually >> >>> + includes this file to suggest defaults for the upstream collection >> >>> + of repositories. >> >> >> >> I dislike this last point. Realistically we don't want this right? So >> >> perhaps we shouldn't include it? >> > >> > I am not sure if I follow. Without .gitmodules, how would you, as a >> > downstream developer, bootstrap the whole thing? >> > >> >> I think Brandon eludes to our long term vision of having a separate >> magic ref containing these informations instead of carrying it in tree. >> >> As urls change over time, it is better to keep the urls out of the >> actual history, but still versioned so maybe we'll want to have >> a ref/submodule-config/master ref that contains all the bootstrapping >> information. The .gitmodules file would degenerate to a pure >> name<->path mapping. > > I was more eluding to having fetch.recurse and the other similar bits > stored in the gitmodules file. Well yes, but these configurations would also go onto the new magic ref once implemented. And to answer your question: Yes we (you and me) dislike it, but it is the best we can do given the current implementation. Once the implementation changes, we may want to adapt this man page. > > -- > Brandon Williams
