Re: [PATCH v6 2/4] submodule update: add --remote for submodule's upstream changes

[Junio C Hamano <gitster@pobox.com>]

"W. Trevor King" <wking@tremily.us> writes:

> As an example to make this clearer:
>
>   $ cat .gitmodules
>   [submodule "sub1"]
>     path = sub1
>     url = git://example.com/sub1.git
>     remote = remote1
>     branch = branch1
>     update-source = submodule-upstream
>     update = rebase
>   [submodule "sub2"]
>   ...

Maybe it is just me but that "remote = remote1" sticks out like a
sore thumb.

If you are showing the .gitmodules file to be shared as hints to
project participants, why does it even need to have both URL and
remote1?  If remote1 points at some other repository, the recipient
of this .gitmodules file would not have any clue where it is.  If
remote1 points at the same repository as the URL, why should it be
there in the first place?  The superproject is in no business to
force what local remote name each participant would call in their
submodule checkout, and more importantly, there is no _need_ to do
so.

We could extend that reasoning to the branch name (which is also a
local matter, at least technically), but this is a lot more
justifiable.  If the upstream of the superproject is the same
organization as the upstream of the submodule project, which is
often the case when a large project is organized as a forest of
submodules bound at the top-level with a superproject, the
superproject commit on a particular superproject branch may want any
update necessary to complete the superproject made to submodules on
specific branches at the central meeting place.  The superproject's
Milestone22 branch may want to bind commits that is on submodule's
Milestone22 branch.

While a participant locally *can* create M22 branch in the submodule
and set it to build upon Milestone22 branch taken from the central
repository, most people don't.  They use the same branch names
between local and remote (i.e. refs/heads/*:refs/remotes/origin/* to
keep the remote-tracking branches under the same name, and the local
branch $any builds upon the corresponding remote-tracking branch
refs/remotes/origin/$any.  Most importantly, the work done on local
branch $any is pushed out to refs/heads/$any at the remote of the
submodule).  Because of how people use "push" to push $any branch to
the branch of the same name $any at the central meeting place, and
because the upstream wants participants to use a particular branch
name in the submodule at the central meeting place, the set-up ends
up dictating what local branch name should be used.

But I do not see any reason to require or even suggest any local
nickname that is to be used to call the remote.  It really is a
local matter.  Why should .gitmodules have "remote = ..." line?

On the other hand, if you meant the above as an excerpt from
$GIT_DIR/config, it also does not make sense.  At that point, the
participant own the file and updating url to point at whatever
different repository without changing the remote name is sufficient.

It looks way over-engineered for unclear/dubious benefit.