Thread (7 messages) flat view 7 messages, 3 authors, 2016-06-15

Re: [PATCH 5/5] Add gitmodules(5)

From: Josef Weidendorfer <hidden>
Date: 2016-06-15 22:43:15

On Tuesday 12 June 2007, Johannes Sixt wrote:
Josef Weidendorfer wrote:
quoted
However, to not have a lot of copies of the admin submodule
in

 .git/submodule/admin
 .git/submodule/kdelibs/.git/submodule/admin
 .git/submodule/kdebase/.git/submodule/admin
 .git/submodule/kdenetwork/.git/submodule/admin

the just suggested submodule.<name>.repopath to specify a repository
outside of .git/submodule to be shared by kdelibs,kdebase,... would
be fine.
This clearly shows that having the repositories of submodules in
.git/submodule does not buy you enough to avoid duplication.
The .git/submodule space for sure is not flexible enough for all
possible use cases of submodules (as with KDE repo).
However, as default it seems fine to me.

IMHO sharing of the admin submodule repository should even be possible
if I have a clone of kdelibs and kdebase independent of the big
KDE superproject.

It would be nice to allow submodule.<name>.repopath configs globally
in ~/.gitconfig, and cloning kdelibs should automatically do the
right thing, ie. use the already available admin repo for the kdelibs
clone.
(I don't see enough reason to place a repo for submodule X in project Y
outside its "natural" checked-out directory in project Y. But then, I
haven't followed the discussion.
To easily share the objects, branches and local modifications?

Currently a clone of a superproject always does a full copy of
any submodule databases because it is independent from any other
local git repository; in the KDE case you would get >4 admin copiess
if recursive cloning of submodules inside of submodules does that.

Josef
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help