Junio C Hamano wrote:
Mark Levedahl <mlevedahl@xxxxxxxxx> writes:
Basically, I think an important (but not complete) test of the design
is that
git clone -o frotz git://frotz.foo.bar/myproject.git
cd myproject
git submodule init
git submodule update
work, with origin = frotz throughout the submodules, and with the
whole project correctly checked out even if the entire project was
rehosted onto a different server.
I like that. This is a very good argument, especially because
it clarifies very well that the issue is not about "'submodule
init' misbehaves" but "fetch/pull/merge does not play well with
clone -o"
Carrying the above forward... Assume I have a checked out project as
above, then in top-level master project I do:
git remote add zoo git://zoo.tar.fu hisfork.git
git fetch zoo
git checkout --track -b fork zoo/fork
git submodule update
I claim the submodule machinery *should* now follow master's default
remote, which is "zoo", for the current branch. In addition, the
submodule machinery should define remote "zoo" in each submodule where
it does not already exist, using the same logic using in the original
init/update phase. This should only apply to modules defined using
relative urls.
Basically, this formalizes the notion that:
* submodules defined using relative urls are "owned" by the master
project and will exist anywhere the master does.
* submodules defined using absolute urls are incorporated into the
project but are separately managed. (While some improved mechanism to
automate their management from top-level may be proposed, it is not
obvious to me nor addressed here.)
The subsequent patch modifies git-submodule to implement this logic, and
applies on top of my previous series.
(Note: I cannot find my latest series in the git-archives on gmane nor
on marc.info, both have only part, and I am suspicious that something
went wrong in my sending via gmail, so I am resending the series here,
now five patches long. Please excuse if this is redundant).
Mark
-
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
