Re: Allow git alias to override existing Git commands

> On Tue, Nov 10, 2015 at 1:57 PM, Jens Lehmann <Jens.Lehmann@web.de> wrote:
>> Am 10.11.2015 um 19:12 schrieb Stefan Beller:
>>> On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton <admin@game-point.net>
>>>> For example, I wanted to setup "git clone" to automatically act as "git
>>>> clone --recursive".  Sure I could do it in the shell, but it's more of a
>>>> pain - any tutorial I set up about doing it would have to worry about
>>>> what
>>>> shell the user was using - and if you're going to make that argument, why
>>>> have "git alias" at all?  It can all be done from the shell.
>>>
>>>
>>> I think the git way for your example would be to configure git to include
>>> that
>>> option by default, something like
>>>
>>>       git config --global submodules.recursiveClone yes
>>>
>>> though I was skimming through the man page of git config and did not find
>>> that option there. I guess it's missing.
>>
>>
>> We thought about adding such a config option, but I believe that would
>> fall a bit short. If I want to have recursive clone I also want to init
>> all those submodules appearing in later fetches too (otherwise the end
>> result would depend on whether you cloned before or after a submodule
>> was added upstream, which is confusing). Extra points for populating
>> the submodule in my work tree when switching to a commit containing
>> the new submodule.
>>
>> So what about a "submodule.autoupdate" config option? If set to true,
>> all submodules not marked "update=none" would automatically be fetched
>> and inited by fetch (and thus clone too) and then checked out (with my
>> recursive update changes) in every work tree manipulating command
>> (again including clone).
>>
>> Users who only want the submodules to be present in the work tree but
>> not automagically updated could set "submodule.autoupdate=clone" to
>> avoid the extra cost of updating the work tree every time they switch
>> between commits. Now that Heiko's config-from-commit changes are in
>> master, someone could easily add that to fetch and clone as the first
>> step. We could also teach clone to make "submodule.autoupdate=true"
>> imply --recursive and execute the "git submodule" command to update
>> the work tree as a first step until the recursive checkout patches
>> are ready.
>>
>> Does that make sense?
>
> I guess.
>
> So the repo tool has the concepts of groups. I plan to add that to git
> eventually, too.
> i.e. with comma separated list that looks like:
>
>      git clone --submodule-groups=default,x86builds,new-phone-codename
>
> Having a new option there there I would also set the
>
>      submodule.autoupdate=all
>
> implicitly which then enables --recurse-submodules on all supported commands.

> By introducing such a new submodule groups option we don't need to tell
> the users about all the new submodule options, but they can still take
> advantage of them,
> I'd assume.
>
> Does that make sense, too?