From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 04 May 2016 21:13:47 GMT
Subject: Re: [RFD/PATCH] submodule doc: describe where we can configure them
Message-ID: <xmqqd1p1frw4.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20160503235652.GA395@google.com>

Jonathan Nieder <jrnieder@gmail.com> writes:

> This design is somewhat problematic for a few reasons:
>
> - When I want to stop paying attention to a particular submodule and
>   start paying attention to it again later, all my local settings are
>   gone.

True; "[submodule "foo"] enabled = no" may also be a way to fix it
without throwing the whole with bathwater, though.

> - When upstream adds a new submodule, I have to do the same manual
>   work to change the options for that new submodule.

Because a new module is not automatically "init"ed by default?

Isn't "config only" vs "config with gitmodules fallback" orthogonal
to that issue?

> - When upstream changes submodule options (perhaps to fix a URL
>   typo), I don't get those updates.

True.

> A fix is to use settings from .git/config when present and fall back
> to .gitmodules when not.  

How would that fix the "upstream updated"?

I think an alternative suggested in an ancient time had a more
elaborate scheme:

 * Use .git/config as the authoritative source, but record
   sufficient information to detect the case and cope with it when
   entry in .gitmodules changes (details below).

 * When seeing a new .gitmodules entry, either by "git pull" or even
   "git checkout other-branch", copy that to .git/config (just like
   what "git submodule init" does).  It would be a policy decision
   to automatically enabling it or not.  If the policy is "no
   autoinit", then "module.<name>.inited = no" may also have to be
   added to .git/config at this point.

   Record contents of the entry in .gitmodules to the corresponding
   .git/config entry as "seen".

 * When the entry in .gitmodules for a submodule known to
   .git/config is different from what has been "seen", offer the
   user a chance to update corresponding .git/config entry, and
   append to the "seen" set of variants in .gitmodules so that the
   user will not be bugged with "we see .gitmodules entry for module
   <foo> is different from anything you have ever seen; do you want
   to make corresponding changes to the module entry in your
   .git/config" again.

which would handle all of the above, and without using anything from
.gitmodules before the user has a chance to vet it.