Re: [PATCHv2] submodules: overhaul documentation
- From
- Brandon Williams <bmwill@google.com>
- Date
- Jun 22, 2017, 21:03 UTC
- Message-ID
- <20170622210323.GC124061@google.com>
- In-Reply-To
- <CAGZ79ka5MkpPSxR23Kz9DcxFkHNB-hz=n-teDXc6=eX4p473FQ@mail.gmail.com>
On 06/22, Stefan Beller wrote:
Show 34 quoted lines
> On Thu, Jun 22, 2017 at 1:20 PM, Junio C Hamano <gitster@pobox.com> wrote: > > Brandon Williams <bmwill@google.com> 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.
-- Brandon Williams