Am 10.11.2015 um 23:49 schrieb Stefan Beller:
On Tue, Nov 10, 2015 at 1:57 PM, Jens Lehmann <jens.lehm...@web.de> wrote:
Am 10.11.2015 um 19:12 schrieb Stefan Beller:
On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton <ad...@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.
And then only submodules contained in these groups would be cloned,
automatically initialized (including those being added to a group by
upstream in the future) and their work trees updated every time the
superproject commit changes? And all submodules that aren't part in
any of these groups would be skipped and neither downloaded nor
updated? Sounds good.
But I'd rather use
submodule.autoupdate=groups
for that use case. I expect "all" to really mean all submodules,
not only those contained in the selected groups.
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?
Yup.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
