Re: [RFC 01/10] submodule: add 'core.submodulesFile' to override the '.gitmodules' path
- From
Stefan Beller <sbeller@google.com>
- Date
- Apr 18, 2018, 18:44 UTC
- Message-ID
- <CAGZ79kb6-JaqUhgb_BdegbmyZowbMwR35UDcvSaXLCvWtVkjmA@mail.gmail.com>
- In-Reply-To
- <20180418134357.1e417fb22201b6a6b67c02c0@ao2.it>
Hi Antonio,
Show 17 quoted lines
>> >> Good point! I wonder if the cleaner solution would be to just >> tell git to use HEAD:.gitmodules and not check out the file? >> then you would not need to come up with a namespace for names >> of the .gitmodules files and scatter them into the worktree as well? >> > > Any solution which: > > 1. prevents the gitmodules file to be checked out > 2. but still tracks it in the git repository > > OR > > 1. allows to set the gitmoudles file under some namespace > > would work for vcsh I guess.
I personally would tend to rather go for supporting your first solution (prevent .gitmodules from checked-out, load from sparse HEAD), but I do not have strong arguments or feeling about this dimension. I am fine with a namespaced .gtimodules solution, too.
Both solutions can be implemented by either:
A) adding the code where it is (like your patch, e.g. using
> - value=$(git config -f .gitmodules submodule."$name"."$option")
> + gitmodules_file=$(git config core.submodulesfile)
> + : ${gitmodules_file:=.gitmodules}
> + value=$(git config -f "$gitmodules_file" submodule."$name"."$option")B) adding a helper, which is a layer of indirection to load the relevant configuration.
And when it comes to this dimension, I'd strongly favor B over A. Having this indirection helper in place enables to add more options later easily as only one place needs to be touched. (These other options could include the other solution as presented above, or the idea with the special ref as mentioned in an earlier email)
Show 29 quoted lines
>> > Can you give an example from the user point of view of such a
>> > "config-from-gitmodules" command?
>> >
>>
>> git submodule config <name> <option>
>>
>> as an 'alias' for
>>
>> gitmodules_file=$(git config core.submodulesfile)
>> : ${gitmodules_file:=.gitmodules}
>> value=$(git config -f "$gitmodules_file"
>> submodule."$name"."$option")
>>
>> The helper would figure out which config file to load form
>> (.gitmodules in tree, HEAD:.gitmodules, your new proposed gitmodules file,
>> .git/config... or the special ref) and then return the <option> for <name>
>>
>> So maybe:
>>
>> $ git clone https://gerrit.googlesource.com/gerrit && cd gerrit
>> # ^ My goto-repo with submodules
>>
>> $ git submodule config "plugins/hooks" URL
>> ../plugins/hooks
>>
>>
>
> I may look into such supporting changes once you decide the approach to
> take for the bigger problem.I think once we have the helper in place you can implement the solution to the bigger problem as you like?
There are a few pros and cons for namespaced .gitmodules and non-checked-out sparse HEAD .gitmodules:
How do you modify the .gitmodules config? ============ In the namespaced solution, you can tell users to edit that file manually or use "git config -f $new_location" to manipulate that file.
In the sparse solution editing becomes a little bit trickier, as you need to edit a file in the index (or HEAD).
If you have the special ref, you could just checkout the special ref in another worktree and make changes and commit there
How do you change the setup? ============ In case of a sparse gitmodules file, you can just check it out (make it non-sparse) or vice versa.
In case of a namespaced gitmodules file, you'd change the config setting and have to move the file to the new location. as git config is just about configuring, the user is left alone with moving the file, or would we have a helper for that? ("git submodule relocate-gitmodules" or such)?
If you have the special ref, you could just checkout the special ref in another worktree and make changes and commit there.
I hope this helps instead of confusing more,
Thanks, Stefan