"W. Trevor King" <wk...@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. -- 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
