Re: [PATCH] RFC: Introduce '.gitorderfile'
- From
Stefan Beller <sbeller@google.com>
- Date
- Jul 13, 2017, 19:20 UTC
- Message-ID
- <CAGZ79kao8=L33jqSFdmYp4NhKfCKDmoqYWvCzuMJ2+Pfq=SYEA@mail.gmail.com>
- In-Reply-To
- <xmqqr2xkw3qt.fsf@gitster.mtv.corp.google.com>
On Thu, Jul 13, 2017 at 12:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
Show 22 quoted lines
> Stefan Beller <sbeller@google.com> writes: > >> On Thu, Jul 13, 2017 at 8:59 AM, Jeff King <peff@peff.net> 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.