Jens Lehmann <Jens.Lehmann@xxxxxx> writes:
> a) "git fetch --all"
>
> The user wanted to fetch new commits from all remotes. I think
> git should also fetch all submodules then, no matter if new
> commits from them are fetched in the superproject, as the user
> explicitly said he wants everything. Objections?
Why? I do not see a "--submodules" option on that command line. The only
thing I asked is to grab all branches for the project I ran "git fetch"
in.
> b) "git fetch [<repository>]"
>
> The user wants to fetch from the default [or a single repo]. I
> think all submodules should be fetched too, Kevin thinks this
> should happen only when it is necessary (at least for his 'H'
> repository). While I think fetching all submodules too is
> consistent with the fact that you get all branches in the
> superproject too, whether you need them or not, we can't seem
> to agree on this one (also see my proposal below).
The case with <repository> is a lot more questionable than the case of
fetching implicitly from whereever you usually fetch from. Imagine that
you fork git.git, and create a separate project that has some nifty
additions to support submodules better. The additional part is naturally
done as a submodule. This jens.git repository becomes very popular and
people clone from it. Your users usually interact with your repository by
saying "git fetch" or "git pull" without any explicit <repository>. They,
however, would want to fetch/pull from me from time to time to get updates
that you haven't incorporated in jens.git repository. "git fetch junio" is
run. Why should such a "fetch" go to your repository and slurp the
objects for the submodules?
Perhaps you would want some knobs like these?
[remote "origin"]
fetch-submodules = all
fetch-submodules = changed
[remote "junio"]
fetch-submodules = none
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...
--
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