On Thu, Jul 13, 2017 at 12:12 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Stefan Beller <sbeller@xxxxxxxxxx> writes: > >> On Thu, Jul 13, 2017 at 8:59 AM, Jeff King <peff@xxxxxxxx> wrote: >>>> This triggers two reactions for me: >>>> >>>> (a) We should totally do that. >>> >>>> (b) It's a rabbit hole to go down. >>> >>> And yes, I had both of those reactions, too. We've had the >>> "project-level .gitconfig" discussion many times over the years. And it >>> generally comes back to "you can ship a snippet of config and then give >>> people a script which adds it to their repo". >> >> I see this "project-level .gitconfig" via the .gitmodules file. >> See GITMODULES(5), anything except submodule.<name>.path is >> just project-level .gitconfig,... > > They were from day one meant as a suggestion made by the project. > You do not have to follow them and you are free to update them, > i.e. after "submodule init" copied URL to point at a closer mirror, > for example. The URL is somewhat special as its copying into the .git/config also marks the submodule as interesting (no matter if the URL is changed by the user). The point I was trying to make is best demonstrated in t5526-fetch-submodules.sh: > ok 7 - using fetchRecurseSubmodules=true in .gitmodules recurses into submodules > ok 8 - --no-recurse-submodules overrides .gitmodules config > ok 9 - using fetchRecurseSubmodules=false in .git/config overrides setting in .gitmodules They were not suggestions, but defaults dictated by the project. If the user did not change their config, they did as the project said. I was not there on day one to remember if they are merely meant as suggestions, but their behavior is asserting.
