Am 13.01.2016 um 23:47 schrieb Stefan Beller:
On Wed, Jan 13, 2016 at 2:03 PM, Junio C Hamano <gitster@xxxxxxxxx> wrote:
Stefan Beller <sbeller@xxxxxxxxxx> writes:
Later on we want to deprecate the `git submodule init` command and make
it implicit in other submodule commands.
I doubt there is a concensus for "deprecate" part to warrant the use
of "we want" here. I tend to think that the latter half of the
sentence is uncontroversial, i.e. it is a good idea to make other
"submodule" subcommands internally call it when it makes sense, and
also make knobs available to other commands like "clone" and
possibly "checkout" so that the users do not have to do the
"submodule init" as a separate step, though.
Maybe I need to rethink my strategy here and deliver a patch series
which includes a complete port of `submodule init`, and maybe even
options in checkout (and clone) to run `submodule init`. That way the
immediate benefit would be clear on why the series is a good idea.
I think that makes lots of sense. It looks to me like clone already
has that option (as --recurse-submodules must init the submodules),
but it might make sense to add such an option to checkout to init
(and then also update) all newly appearing submodules (just like
"git submodule update" has the --init option for the same purpose).
The current wording is mostly arguing to Jens, how to do the submodule
groups thing later on, but skipping the immediate steps.
I really believe that in the future a lot of users will hop on to the
automatically-init-and-update-submodules train once we have it (and I
think users of the groups feature want to be on that train by default).
But I also believe we'll have to support the old school init-manually
and update-when-I-want-to use cases for a very long time, as lots of
work flows are built around that.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html