Am 07.10.2010 00:52, schrieb Kevin Ballard:
> On Oct 5, 2010, at 2:06 PM, Junio C Hamano wrote:
>> I dunno. I've never been a fan of automatically recursing into submodules
>> (iow, treating the nested structure as if there is no nesting), so...
>
> I agree with this as well.
There are use cases like mine where automatic recursion is just the right
thing to do. But I would be fine with having to turn the recursion on
explicitly in the configuration if most people think recursion is not a
desirable default. It would be really nice to hear from other submodule
users what they think about that ...
> After thinking on it a bit, I think the best solution is to add a switch
> --submodules to fetch which will also fetch all submodules, but otherwise
> fetch will fetch no submodules. This will avoid the problem of detecting
> changed submodules, while still allowing users to explicitly request all
> submodules in case they're about to get on a plane flight.
> And of course we can use a config switch to turn --submodules on or off
> by default.
And apart from the default setting and the name of the option this is
exactly what this patch series does, or am I missing something? I could
rename the option from '--recursive' to '--submodules' if that is
requested (I chose the former for consistency reasons as it is already
used by "git clone" for the same purpose; and IMO we should then use
the same option name for recursive checkout and grep too).
> We should also give some thought to automatically updating submodules
> when `git pull` is performed. I could imagine `git pull --submodules`
> effectively doing `git pull && git submodule update --init --recursive`,
> though this implies submodule updating behavior as part of merge, and
> it seems harder to justify that.
This is the goal of my recursive checkout effort ("update" being the
easier part, "--init" the harder). And if you have recursive checkout
enabled, I think it is justified to update the submodules as part of
the merge.
--
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